Is Copilot Studio Replacing Low-Code Developers: The Future of Managed Business Logic

Azure Disk Storage - Simply Explained

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're diving into one of the most important building blocks of every Azure Virtual Machine: Azure Disk Storage. Every VM relies on disks for its operating system, applications, and data—but choosing the wrong disk type can either slow your workloads down or significantly increase your cloud costs. In this episode, you'll learn the differences between Standard SSD, Premium SSD, Premium SSD v2, and Ultra Disk. We'll explain IOPS, throughput, latency, OS disks versus data disks, redundancy options, snapshots, security, and how to select the right storage tier for your workloads without overspending. WHY AZURE DISK STORAGE MATTERS Azure Disk Storage provides persistent block storage for Azure Virtual Machines. Unlike temporary storage that disappears when a VM shuts down, managed disks remain attached to your VM and retain all data through reboots, maintenance events, and VM deallocations. Choosing the correct disk type directly impacts three key performance metrics: * IOPS (Input/Output Operations Per Second) determines how many read and write operations the disk can process. * Throughput measures how much data can be transferred every second. * Latency represents how quickly data begins transferring after a request. Higher performance disks deliver faster applications and databases but also come with higher costs. The goal is to match your workload's actual requirements rather than simply choosing the fastest option available. OS DISKS VS DATA DISKS Every Azure Virtual Machine automatically receives an Operating System Disk that stores Windows or Linux and allows the VM to boot. OS disks can be up to 4 TB in size and are optimized for hosting the operating system and core software. Additional Data Disks can be attached separately to store databases, applications, file repositories, or business data. Individual data disks can reach up to 64 TB, and multiple disks can be attached to a single VM depending on the VM size. Both OS disks and data disks support the same performance tiers, allowing organizations to independently optimize storage performance for operating systems and application workloads. UNDERSTANDING THE FOUR DISK TYPES Azure offers four primary managed disk performance tiers. Standard SSD provides affordable SSD performance for development, testing, low-traffic websites, and lightweight applications. It offers solid performance at the lowest SSD price but isn't recommended for demanding production databases. Premium SSD is designed for production workloads, virtual desktops, and business applications requiring consistently low latency. Performance scales with disk size, meaning larger disks provide more IOPS and throughput. Premium SSD v2 introduces independent scaling for storage capacity, IOPS, and throughput. Instead of purchasing additional storage simply to gain performance, organizations can configure each resource independently, significantly reducing costs while supporting enterprise databases and business-critical applications. Ultra Disk delivers Azure's highest storage performance with extremely low latency, hundreds of thousands of IOPS, and throughput measured in gigabytes per second. It's built for mission-critical systems such as SAP HANA, financial trading platforms, healthcare applications, and massive enterprise databases where every microsecond matters. CHOOSING THE RIGHT DISK Selecting the right Azure managed disk starts with understanding your workload. Development and testing environments usually perform perfectly with Standard SSD, helping reduce cloud costs. Most production workloads benefit from Premium SSD, while Premium SSD v2 offers the best balance between flexibility, performance, and pricing for modern enterprise applications. Ultra Disk should only be selected when workloads genuinely require extreme IOPS, ultra-low latency, or exceptionally high throughput. For the majority of Azure deployments, Premium SSD v2 provides nearly all the required performance at a considerably lower cost. Proper sizing also helps avoid unnecessary expenses by matching storage capacity and performance to real business requirements rather than overprovisioning resources. SECURITY, REDUNDANCY, AND SNAPSHOTS Azure Disk Storage includes enterprise-grade protection out of the box. All managed disks are encrypted by default using 256-bit AES server-side encryption, with optional customer-managed keys for organizations requiring full control over encryption. Azure supports both Locally Redundant Storage (LRS) and Zone-Redundant Storage (ZRS), allowing businesses to balance cost with resiliency depending on their availability requirements. Snapshots create point-in-time backups of managed disks without interrupting workloads. New Instant Access Snapshots for Premium SSD v2 and Ultra Disk dramatically reduce recovery times, making disaster recovery significantly faster than traditional snapshot restoration methods. Combined with Azure's built-in durability and high availability, managed disks provide a secure and resilient storage platform for business-critical virtual machines. KEY TAKEAWAYS Azure Disk Storage is the foundation of every Azure Virtual Machine. Understanding the differences between Standard SSD, Premium SSD, Premium SSD v2, and Ultra Disk allows you to optimize both performance and cost. Choose Standard SSD for development workloads, Premium SSD for reliable production systems, Premium SSD v2 for flexible enterprise performance, and Ultra Disk only when your applications truly require maximum throughput and the lowest possible latency. Selecting the right managed disk ensures your Azure workloads remain fast, resilient, secure, and cost-efficient while giving you the flexibility to scale as your infrastructure grows. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support [https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support?utm_source=rss&utm_medium=rss&utm_campaign=rss].

Azure Blob Storage - Simply Explained

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring one of the most fundamental Azure services that powers websites, AI applications, backups, analytics, and countless cloud-native solutions: Azure Blob Storage. Although almost every Azure customer uses it in some way, many IT professionals only have a vague understanding of what it actually is and why it has become the standard for storing unstructured data in Microsoft Azure. Throughout this episode, you'll learn how Blob Storage organizes data, why object storage is different from traditional file servers, the different blob types available, how Azure automatically manages storage costs through access tiers, and how lifecycle management, security, redundancy, and scalability make Blob Storage suitable for everything from personal applications to enterprise-scale AI workloads. WHAT IS AZURE BLOB STORAGE? Azure Blob Storage is Microsoft's cloud-based object storage service designed for storing massive amounts of unstructured data. Unlike databases that organize information into tables or traditional file servers that rely on folder structures, Blob Storage is optimized for files such as images, videos, backups, PDFs, application logs, AI datasets, and virtually any other binary content. The name Blob stands for Binary Large Object, which simply describes large pieces of binary data stored together with metadata. Instead of worrying about disks, servers, RAID arrays, or storage hardware, Azure takes care of availability, replication, scalability, and durability behind the scenes. One of the biggest differences compared to traditional storage is that Blob Storage uses a flat object model rather than a physical folder hierarchy. While Azure presents virtual folders for convenience, every blob actually exists inside a container with its own unique URL, making the platform incredibly scalable while simplifying access for applications around the world.  STORAGE ACCOUNT, CONTAINERS, AND BLOBS Blob Storage follows a simple three-level hierarchy. Everything begins with a Storage Account, which serves as the top-level namespace and defines settings such as performance, redundancy, and security. Every storage account receives a globally unique name because it becomes part of every storage URL. Inside the storage account are Containers. Containers are comparable to top-level folders, although unlike traditional file systems they cannot contain other containers. They provide logical separation between different types of data, such as backups, images, application logs, or AI training datasets. Finally, the actual files are stored as Blobs. Every blob has its own URL and may contain additional metadata such as content type, project information, retention settings, or custom application tags. This metadata allows Azure services to automate lifecycle management, search, indexing, and storage optimization without modifying the file itself. UNDERSTANDING THE THREE BLOB TYPES Azure offers three different blob types, each optimized for a different workload. Block Blobs are by far the most common option and are used for documents, images, videos, backups, software packages, and AI datasets. Azure uploads these files in multiple blocks, allowing parallel uploads, resumable transfers, and excellent performance even for multi-terabyte files. Append Blobs are designed for continuously growing data. Instead of modifying existing content, new information is always appended to the end of the blob, making this format ideal for application logs, audit trails, telemetry, and IoT sensor data. Page Blobs work differently by allowing random read and write operations across fixed-size pages. This makes them perfect for Azure Virtual Machine disks where operating systems require constant random access to storage rather than sequential uploads. Choosing the right blob type ensures optimal performance while minimizing storage costs and improving application efficiency.  HOT, COOL, COLD, AND ARCHIVE TIERS One of Azure Blob Storage's biggest strengths is its ability to optimize costs through multiple storage tiers. The Hot tier is intended for frequently accessed data such as active websites, customer images, or current project files. Storage costs are higher, but access costs remain low. The Cool tier reduces storage costs significantly while increasing access costs, making it ideal for files that are only needed occasionally, such as monthly reports or recent backups. The newer Cold tier is designed for information that may only be accessed a few times per year, providing an additional balance between storage cost and retrieval cost. Finally, the Archive tier offers the lowest storage price available in Azure. Data stored here is kept offline and must first be rehydrated before it can be accessed, making Archive ideal for compliance records, historical backups, and long-term retention requirements. Selecting the correct tier based on access frequency can dramatically reduce storage costs without sacrificing durability or security.  AUTOMATING STORAGE WITH LIFECYCLE MANAGEMENT Instead of manually moving files between storage tiers, Azure provides built-in Lifecycle Management. Administrators simply define rules that automatically move blobs between Hot, Cool, Cold, and Archive based on conditions such as creation date, modification date, or last access time. Lifecycle policies can also permanently delete outdated data after a specified retention period. For example, backups might remain in the Hot tier for 30 days, automatically move to Cool storage after one month, transition to Archive after 90 days, and finally be deleted after one year. This automation reduces operational overhead, minimizes storage costs, and ensures consistent data retention policies across thousands—or even billions—of stored objects.  SECURITY, REDUNDANCY, AND REAL-WORLD USE CASES Azure Blob Storage includes enterprise-grade security features including Microsoft Entra ID integration, Azure RBAC, Shared Access Signatures (SAS), encryption at rest, private endpoints, firewall rules, soft delete, immutable storage, and customer-managed encryption keys. To protect data against hardware failures or regional disasters, Azure also offers multiple redundancy models including LRS, ZRS, GRS, and GZRS, allowing organizations to choose the right balance between cost, availability, and disaster recovery capabilities. Blob Storage powers an enormous range of real-world workloads including: * Virtual machine backups * Disaster recovery * Website images and videos * Azure Data Lake Storage * AI and machine learning datasets * Application logging * IoT telemetry * Software distribution * Static website hosting * Enterprise document repositories Its combination of virtually unlimited scalability, extremely high durability, flexible pricing, and worldwide availability makes Azure Blob Storage one of the most widely used cloud storage platforms available today. KEY TAKEAWAYS Azure Blob Storage is much more than a place to upload files. It is Microsoft's highly scalable object storage platform designed to handle everything from simple document storage to petabyte-scale AI datasets. Understanding the hierarchy of storage accounts, containers, and blobs, selecting the appropriate blob type, choosing the correct storage tier, and leveraging lifecycle management allows organizations to build cloud-native solutions that are both cost-efficient and highly resilient. Whether you're building modern web applications, storing backups, powering analytics platforms, or training AI models, Azure Blob Storage provides the foundation for reliable, secure, and massively scalable cloud storage. In the next episode, we'll compare Azure Files and Azure Blob Storage to help you understand when each service is the better choice. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support [https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support?utm_source=rss&utm_medium=rss&utm_campaign=rss].

Scaling CI-CD: The Governance Blueprint

modern platform governance works differently. Rather than enforcing compliance through documentation and manual reviews, governance is embedded directly into templates. These templates automatically include: * Security scanning * Dependency validation * Approval gates * Secrets management * Naming standards * Audit logging Because these controls are built into the platform itself, development teams don't need to remember every policy. The safest path also becomes the easiest path. GOLDEN PATHS A major concept introduced in this episode is the Golden Path. Instead of giving developers blank pipeline templates, organizations provide opinionated deployment paths that already include best practices. Golden Paths define standard approaches for: * Building applications * Running automated tests * Performing security validation * Deploying through environments * Rolling back failed releases Most services can successfully use only a small number of Golden Path templates, while exceptional workloads extend rather than replace the standard model. This dramatically reduces onboarding time and ensures consistency across engineering teams. RING-BASED DEPLOYMENTS Safe deployment at scale requires limiting the blast radius of every release. The episode introduces Microsoft's Ring Deployment model. Instead of deploying directly to every user, releases move progressively through increasingly larger audiences. Typical deployment rings include: * Ring 0 – Internal engineering teams * Ring 1 – Pilot users * Ring 2 – Broad production Each promotion depends on predefined success criteria including deployment success, latency, error rates, business metrics, and overall system health. Only after a ring meets its objectives does the deployment continue to the next stage. CANARY RELEASES While ring deployments target groups of users, Canary Releases gradually increase traffic to a new application version. Instead of exposing everyone immediately, perhaps only 1% of requests use the new version. Observability platforms continuously compare: * Error rates * Response times * Business KPIs * User behavior If performance remains healthy, traffic gradually increases. If problems appear, traffic immediately returns to the stable version. This minimizes deployment risk while providing real production feedback before a full rollout. OBSERVABILITY AND AUTOMATED PROMOTION Deployment governance depends on reliable measurement. Observability provides: * Distributed tracing * Centralized logging * Performance metrics * Health dashboards These measurements feed automated promotion gates that determine whether deployments satisfy predefined quality thresholds. Instead of requiring manual approval for every promotion, policies evaluate real production metrics and automatically decide whether deployments may continue through the release pipeline. This dramatically reduces deployment latency while maintaining high confidence in production quality. PLATFORM AS A PRODUCT One of the strongest messages throughout the episode is that internal platforms should be treated like products. Platform teams should measure: * Developer satisfaction * Adoption rates * Time to first deployment * Self-service success * Golden Path usage If engineering teams actively choose the platform because it simplifies their work, governance becomes nearly invisible. The platform succeeds not because people are forced to use it, but because it removes friction from software delivery. IMPLEMENTING THE BLUEPRINT Successful platform transformations happen gradually. Organizations typically begin by identifying the largest deployment pain point before introducing a single Golden Path and a small platform team. As adoption grows, reusable templates, automated governance, observability, ring deployments, and policy-driven promotion gradually become the standard operating model. Leadership support is critical because platform engineering requires cultural change as much as technical implementation. Teams move from owning individual pipelines to participating in a shared delivery ecosystem that improves reliability, security, and developer productivity.  KEY TAKEAWAYS Scaling CI/CD isn't about choosing a better pipeline tool. It's about designing a repeatable operating model. Organizations that standardize deployment through reusable templates, Golden Paths, platform governance, ring-based deployments, automated promotion gates, and strong observability can dramatically reduce cognitive load, improve developer productivity, lower operational costs, and strengthen security. The most successful platform teams don't build infrastructure that developers are forced to use—they build products that developers genuinely want to use. By making governance invisible, embedding best practices into templates, and continuously improving the developer experience, organizations create delivery platforms that scale from a handful of teams to hundreds without sacrificing speed, quality, or compliance. Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support [https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support?utm_source=rss&utm_medium=rss&utm_campaign=rss].

The Monorepo Myth: Why Your Architecture Is Fragmented

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're tackling one of the biggest misconceptions in software architecture: the Monorepo Myth. For years, engineering teams have debated whether a monorepo or a multirepo is the "correct" repository strategy. Discussions usually focus on Git performance, build speed, repository size, or tooling. But these technical arguments miss the real issue. Your repository strategy isn't primarily a Git decision—it's an organizational decision. The structure of your repositories shapes how teams collaborate, communicate, make decisions, and ultimately how quickly your organization can deliver software. THE BIGGEST MISCONCEPTION Most organizations evaluate repository strategies using technical criteria. Questions like: * Can Git handle millions of files? * How fast are clone operations? * How quickly does CI complete? * Which strategy scales better? These are valid engineering concerns, but they aren't the questions that determine long-term success. The real question is: Where does your organization pay its coordination cost? A repository strategy doesn't eliminate coordination—it simply determines where that coordination happens. Whether you choose a monorepo or a multirepo, your teams still need to collaborate. The only difference is how visible that collaboration becomes. UNDERSTANDING MONOREPOS A monorepo stores multiple applications, services, libraries, infrastructure code, and shared components inside a single repository. This creates several important advantages: * Shared tooling * Consistent standards * Easier large-scale refactoring * Unified dependency management * Atomic cross-project changes * Complete visibility across the entire system When teams are closely aligned, a monorepo enables rapid cross-cutting changes because everything lives together under one build system and one source of truth. However, as organizations grow, coordination becomes increasingly centralized. Shared libraries require approval from multiple teams, dependency updates affect everyone simultaneously, and build systems become more complex as additional teams join the repository. The technical challenges often blamed on monorepos are actually symptoms of growing organizational complexity rather than limitations of Git itself. THE HIDDEN COST OF MONOREPOS Large monorepos rarely fail because of technology. Git itself can manage repositories containing millions of files. Companies like Google successfully operate enormous monorepos. Instead, organizations encounter problems such as: * Slow code reviews * Long build pipelines * Complex branching strategies * Frozen dependencies * Endless coordination meetings * Difficult release planning These issues arise because every significant architectural decision requires agreement across more teams. As organizations grow, the repository doesn't become technically unmanageable—it becomes organizationally expensive. The true scaling challenge is coordination, not source control. HOW MULTIREPOS WORK A multirepo architecture separates services, products, or components into independent repositories. Each team owns its own repository, deployment pipeline, testing strategy, and release schedule. The benefits include: * Independent deployments * Clear ownership * Team autonomy * Smaller repositories * Faster local builds * Flexible release cycles However, the coordination burden doesn't disappear. Instead of coordinating through code reviews and shared repositories, teams coordinate through: * APIs * Versioning * Release notes * Contracts * Documentation * Governance processes The coordination simply moves from code into communication between teams. ORGANIZATIONAL DEBT One of the most valuable ideas discussed in this episode is organizational debt. Unlike technical debt, organizational debt doesn't exist in the codebase. It appears as: * Unclear ownership * Slow approvals * Excessive meetings * Complicated release processes * Duplicate workflows * Ambiguous decision-making These problems accumulate over time and become the real bottleneck for software delivery. Many organizations attempt to solve organizational debt by changing repository strategies. In reality, neither monorepos nor multirepos solve these problems—they simply expose them differently. CONWAY'S LAW  A key concept behind repository design is Conway's Law. It states that software systems naturally mirror the communication structure of the organizations that build them. If teams are divided into silos, the architecture will eventually become siloed as well. Changing repository layouts cannot fix poor communication. Likewise, organizations with highly collaborative teams can successfully operate either monorepos or multirepos because the underlying communication patterns already support effective collaboration. Your repository structure is often a reflection of your organizational structure rather than its cause.  THE COMMUNICATION ARCHITECTURE MODEL Rather than thinking about repositories as storage mechanisms, it is more useful to think of them as communication architectures. A monorepo encourages: * Shared visibility * Continuous collaboration * Immediate feedback * Centralized coordination A multirepo encourages: * Clear contracts * Independent ownership * Explicit APIs * Autonomous deployments Neither model is inherently superior. The best choice depends on how your teams naturally communicate and collaborate. Repository strategy should reflect your communication model—not dictate it. AI IS CHANGING THE EQUATION The rapid adoption of AI-assisted development introduces a new challenge. AI coding assistants dramatically increase software output. Developers can generate significantly more code than before, but code review and verification have not accelerated at the same pace. This creates what can be described as a verification tax. Organizations capable of generating code twice as fast often find that reviews, architectural validation, testing, and integration become the new bottlenecks. AI doesn't eliminate organizational fragmentation—it amplifies it by increasing the volume of work flowing through existing coordination processes.  Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support [https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support?utm_source=rss&utm_medium=rss&utm_campaign=rss].

Microsoft Graph Data Connect - Simply Explained

Welcome to another episode of Knowledge Nuggets with Mirko Peters. In this episode, we're exploring Microsoft Graph Data Connect, Microsoft's enterprise-scale solution for extracting large volumes of Microsoft 365 data into Azure or Microsoft Fabric for analytics, reporting, machine learning, security investigations, and governance. While the regular Microsoft Graph API works well for real-time requests and smaller datasets, it becomes difficult to manage when organizations need to extract millions of records across SharePoint, Teams, Exchange, OneDrive, and other Microsoft 365 services. Graph Data Connect solves that scale problem through scheduled bulk data pipelines that avoid traditional API pagination and throttling. WHY MICROSOFT 365 DATA IS DIFFICULT TO EXTRACT Microsoft 365 generates enormous volumes of business activity every day. Emails, Teams messages, meetings, files, site activity, user interactions, and collaboration signals continuously accumulate across the tenant. The Microsoft Graph API provides access to this information through individual requests. This works well when an application needs a limited number of records in real time. However, large-scale analytics projects quickly encounter pagination, rate limits, HTTP 429 throttling responses, retry logic, and long processing times. Trying to analyze every SharePoint site, mailbox, or Teams interaction across a large organization using traditional API calls can take hours or days. Graph Data Connect was designed specifically for these scenarios, allowing organizations to extract Microsoft 365 datasets in bulk rather than requesting records individually.  WHAT IS MICROSOFT GRAPH DATA CONNECT? Microsoft Graph Data Connect is a secure bulk data extraction service for Microsoft 365. It allows organizations to define a dataset, select a destination, and run a scheduled pipeline that transfers large volumes of Microsoft 365 data directly into an analytics environment. The extracted data can include information from services such as: * Microsoft Teams * SharePoint Online * OneDrive * Exchange Online * Microsoft 365 Groups * User and collaboration activity The data is delivered in analytics-friendly formats such as Delta Parquet, making it ready for SQL queries, Power BI reports, machine learning models, and large-scale processing inside Microsoft Fabric or Azure. Graph Data Connect is not a replacement for the Microsoft Graph API. The Graph API is designed for real-time application requests, while Data Connect is optimized for scheduled bulk extraction across an entire Microsoft 365 tenant. GRAPH API, GRAPH CONNECTORS, AND DATA CONNECT These three Microsoft Graph technologies solve very different problems. The Microsoft Graph API retrieves Microsoft 365 information through real-time request-and-response calls. It is ideal for applications that need current information about individual users, messages, files, or calendar events. Microsoft Graph Connectors bring external information into Microsoft 365 so it can appear in Microsoft Search and Copilot. Their purpose is ingestion and indexing. Microsoft Graph Data Connect moves Microsoft 365 data out of the tenant and into an external analytics environment. Its purpose is large-scale extraction. A simple way to remember the difference is: * Graph API: request individual Microsoft 365 records * Graph Connectors: bring external data into Microsoft 365 * Graph Data Connect: export Microsoft 365 data for analytics Understanding this distinction helps organizations select the correct tool instead of forcing a real-time API or automation platform to perform bulk analytics workloads. SECURITY, PRIVACY, AND GOVERNANCE Because Graph Data Connect can process sensitive organizational information, its security model includes strict governance controls. Every application requires explicit administrator approval before it can access Microsoft 365 datasets. Administrators can control which datasets and properties are available, ensuring that applications receive only the information required for the approved business scenario. Data is encrypted during transfer, and organizations can use customer-managed encryption keys through Azure Key Vault for additional control. Identity obfuscation can replace personal identifiers with non-reversible tokens, allowing organizations to analyze collaboration patterns and behavioral trends without directly exposing individual identities. Every extraction is logged, creating an audit trail showing which application accessed the data, who approved it, which datasets were transferred, and when the pipeline ran. These controls make Graph Data Connect suitable for regulated industries and privacy-sensitive analytics scenarios.  WHERE THE DATA CAN GO Graph Data Connect integrates with modern Azure and Microsoft analytics platforms. Organizations can deliver extracted data into: * Microsoft Fabric Lakehouses * Azure Data Lake Storage * Azure Blob Storage * Azure Synapse Analytics * Azure Data Factory pipelines * Custom analytics platforms through additional processing pipelines Microsoft Fabric provides one of the most accessible destinations because the extracted data arrives in Delta Parquet format and can immediately be analyzed using SQL, notebooks, Power BI, or machine learning tools. Once the data has been extracted, it can also be combined with information from CRM, ERP, HR, security, and operational systems to create a broader view of organizational performance. REAL-WORLD USE CASES Microsoft Graph Data Connect supports a wide range of enterprise analytics scenarios. Security analytics can detect unusual account behavior, suspicious file activity, abnormal downloads, or unexpected access patterns. Collaboration analytics can examine how teams communicate, which departments work together, and where organizational bottlenecks exist. Content governance can identify stale SharePoint files, duplicate documents, abandoned sites, excessive permissions, and sensitive information. Employee experience analytics can combine Microsoft 365 collaboration signals with HR information while protecting individual identities. Copilot readiness assessments can help organizations understand where information is stored, how permissions are configured, and whether sensitive content could be exposed before deploying Microsoft 365 Copilot. These use cases require large datasets that would be difficult or impractical to retrieve through standard Graph API requests.  HOW TO SET UP GRAPH DATA CONNECT A typical Graph Data Connect implementation involves several steps. First, Graph Data Connect must be enabled in the Microsoft 365 Admin Center. Administrators then select which datasets should be available. Next, an application registration is created in Microsoft Entra ID to provide the extraction pipeline with a secure identity. A Graph Data Connect application is then configured and linked to the app registration. Administrators select the approved datasets, properties, and destination. The application must pass an explicit Microsoft 365 administrator approval process before it can access organizational information. Finally, a data pipeline is created in Microsoft Fabric or Azure Data Factory. The pipeline selects the Microsoft 365 dataset, applies filters, defines the destination, and schedules the extraction. Once the preparation stage is complete, the data is delivered in structured files that can be analyzed using Power BI, SQL, notebooks, or machine learning tools.  LIMITATIONS AND CONSIDERATIONS Graph Data Connect is designed for scheduled analytics rather than real-time applications. Pipeline runs include preparation time before data begins transferring, which means the service is better suited to nightly, weekly, or periodic analytics jobs than live dashboards. Not every Microsoft 365 property is available through every dataset, so organizations should confirm dataset coverage before designing a solution. Each application requires administrative approval, and changes to requested datasets or properties may require additional consent. Graph Data Connect also uses consumption-based pricing, meaning larger tenants and broader datasets can generate substantial processing costs. Testing with a limited dataset before scaling to the entire tenant is therefore recommended. The platform also requires knowledge of data pipelines, storage formats, identity management, and governance. It is intended primarily for data engineering and enterprise analytics teams rather than simple citizen-development workflows.  Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support [https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support?utm_source=rss&utm_medium=rss&utm_campaign=rss].