Author: Ash

  • OneLake Governance, Performance Optimization & Real-World Use Cases

    ← Back to Microsoft Fabric — Complete Learning Series

    OneLake in Practice: Governance, Performance, and Real-World Use Cases (Part 5)

    This is the final part of a five-part series on Microsoft OneLake. In this closing installment, we focus on the operational backbone that makes OneLake successful at scale: centralized governance with Purview, a robust workspace strategy, performance optimization patterns, and practical real-world use cases that bring the concepts together.

    OneLake Governance — Purview Integration

    OneLake is governed centrally through Microsoft Purview, which provides a single, unified governance layer across the entire Fabric platform. Instead of each data product or service managing its own rules and policies, Purview becomes the authoritative system of record for how data is discovered, protected, and accessed.

    Key Governance Capabilities

    Purview brings a set of core capabilities to OneLake that apply consistently across dataflows, warehouses, lakehouses, BI models, and machine learning environments:

    • Lineage — Track how data moves and transforms from source systems through pipelines, lakehouses, warehouses, and reports, so you always know where a dataset came from and how it is used.
    • Sensitivity labels — Classify and protect sensitive information (such as confidential, internal, or public data) with labels that follow the data across services.
    • Access control — Define who can see and use specific data assets, applying consistent access policies across the entire Fabric environment.
    • Classification — Automatically or manually categorize data based on content and patterns, making it easier to find, understand, and govern at scale.
    • Audit logs — Capture detailed records of who accessed which data and when, providing traceability for compliance, security, and troubleshooting.
    • Policy enforcement — Apply and enforce governance rules centrally, ensuring that data usage aligns with regulatory, security, and organizational requirements.

    Why Centralized Governance Matters

    With OneLake, governance is no longer scattered across dataflows, warehouses, data lakes, BI models, and machine learning environments. Purview provides a single place to define and manage policies, so you do not need to duplicate rules in each tool or service. This reduces risk, simplifies audits, and makes it easier for teams to adopt consistent data practices across the organization.

    OneLake Workspace Strategy — The Enterprise Backbone

    A strong workspace strategy is essential for using OneLake effectively in an enterprise context. Workspaces act as the organizing backbone for projects, domains, and teams, defining how artifacts are grouped, secured, and deployed.

    Best Practices for Workspace Design

    • Dev/Test/Prod separation — Use dedicated workspaces for development, testing, and production to keep experimental work away from business-critical solutions and enable controlled promotion of changes.
    • Clear ownership — Assign explicit owners for each workspace so it is always clear who is accountable for data quality, access, and lifecycle management.
    • Naming conventions — Establish consistent workspace and artifact naming standards to make it easy for people to discover and understand what each environment is for.
    • RBAC roles — Apply role-based access control so contributors, viewers, and administrators have the right level of access, aligned with least-privilege principles.
    • Deployment pipelines — Use deployment pipelines to promote content from development to test and production workspaces in a controlled, repeatable way.
    • Cost management — Organize workspaces so that usage and spend can be attributed to specific teams or projects, helping you monitor and optimize costs.
    • Artifact organization — Group related items such as lakehouses, warehouses, reports, and notebooks logically within workspaces so solutions remain understandable as they grow.

    When designed well, workspaces keep OneLake clean, scalable, and secure. They provide the structure needed for teams to collaborate efficiently while maintaining proper controls.

    OneLake Performance Optimization

    Performance in OneLake depends on a combination of table design, file layout, and query patterns. Applying a few core optimization techniques can significantly improve responsiveness for analytics, dashboards, and downstream workloads.

    Partitioning for Efficient Access

    Partitioning large tables helps engines read only the data that is relevant to a query. In OneLake, common partitioning strategies include:

    • Date — Partition by ingestion date, transaction date, or another time attribute to accelerate time-based filtering and retention policies.
    • Region — Split data by geography or business region to localize queries and reduce the volume of data scanned.
    • Category — Partition on key business categories when they are frequently used as filters, helping queries bypass irrelevant partitions.

    Delta Lake Optimization

    Delta tables in OneLake benefit from targeted optimizations that keep them performant over time:

    • Z-Order — Optimize data layout on disk by clustering files around frequently filtered columns to improve query pruning.
    • File compaction — Periodically merge smaller files into larger ones to reduce overhead and speed up scans.
    • Vacuum — Remove obsolete files created by updates and deletes to keep storage tidy and avoid unnecessary reads.
    • Schema evolution handling — Manage changes to table schemas in a controlled way so that evolving data structures do not degrade performance or reliability.

    Avoiding Tiny Files

    Large numbers of tiny files can significantly slow down queries because each file introduces overhead. Use compaction routines to merge small files into fewer, larger files so engines spend more time processing data and less time managing file metadata.

    Designing for BI with Gold Tables

    For business intelligence scenarios, OneLake works best when Direct Lake connects to curated gold tables. Bronze and silver layers are optimized for ingestion and transformation, not for direct reporting. Always expose clean, conformed gold tables to BI tools so reports remain fast, stable, and easy to maintain.

    Modeling with Star Schemas and Aggregations

    Logical modeling remains critical for performance:

    • Use star schemas — Organize data into fact and dimension tables to simplify queries and enable engines to optimize joins and filters efficiently.
    • Use aggregations — Take advantage of aggregation tables in Fabric to pre-calculate metrics at higher levels (such as daily or monthly) and accelerate common queries.

    Real-World Use Cases

    With governance, workspaces, and performance foundations in place, OneLake can support a wide range of real-world scenarios. The following examples illustrate how organizations can simplify their architectures and unlock new value.

    Enterprise Data Lake Modernization

    Organizations can replace multiple, fragmented data lakes with a single OneLake implementation. Instead of maintaining separate storage accounts and governance models for each platform or business unit, data lands in one logical lake with a common set of policies, formats, and tooling.

    Real-Time Sales Dashboards

    Using Direct Lake in combination with Event Streams, sales data can flow continuously into OneLake and be surfaced in near real time. Dashboards built on top of this data provide up-to-date views of performance without complex streaming architectures outside the Fabric ecosystem.

    Supply Chain Visibility

    OneLake can unify data from warehouses, ERP systems, and IoT sensors into a single platform. This integrated view gives supply chain teams better visibility into inventory levels, lead times, and operational performance, without moving between disconnected systems.

    Financial Reporting

    Finance teams can rely on OneLake as a single source of truth for financial data. By consolidating data from multiple systems into well-governed, curated tables, organizations can simplify reporting processes and reduce reconciliation effort.

    Customer 360

    Customer 360 initiatives benefit from OneLake by unifying customer data across operational systems, interaction channels, and analytical stores. With everything in one place, teams can build richer insights into customer behavior and support more personalized experiences.

    Conclusion — OneLake Is the Foundation of the Unified Future

    OneLake is not just storage. It is the foundation of Microsoft Fabric’s unified analytics platform, bringing data from across the organization into a single, governed environment. By centralizing data and governance, it becomes easier to build reliable data products that scale.

    OneLake replaces fragmented architectures with one lake, one security model, one governance layer, one storage format, and one experience. This consolidation streamlines how teams ingest, manage, and consume data, and reduces the complexity associated with maintaining many disconnected systems.

    As a result, OneLake enables faster development, lower costs, real-time insights, simplified architecture, higher performance, stronger collaboration, and enterprise-grade scalability. Organizations that adopt OneLake early are well positioned to define the next decade of data innovation on top of a unified, governed platform.

    ← Previous: [Link to Part 4]

    ← Back to Microsoft Fabric — Complete Learning Series

    ← Back to Microsoft Fabric — Complete Learning Series

  • Medallion Architecture & Delta Lake in Microsoft Fabric Lakehouse

    Lakehouse Deep Dive, Part 2: Medallion Design, Storage, and Delta Lake

    This post is Part 2 of the Lakehouse series and focuses on three areas: Medallion Architecture as the Lakehouse’s natural design pattern, Lakehouse storage using files and Delta tables, and Delta Lake as the engine that powers the Lakehouse.

    Medallion Architecture: The Lakehouse’s Natural Design Pattern

    This section covers Medallion Architecture and explains why it is a natural design pattern for the Lakehouse.

    Bronze, Silver, and Gold Explained

    This part of the deep dive focuses on Bronze, Silver, and Gold layers and how they are explained within the Medallion Architecture.

    Why Medallion Works Perfectly in Fabric

    This part describes why the Medallion Architecture works particularly well in Fabric.

    Lakehouse Storage: Files and Delta Tables

    This section of the deep dive covers Lakehouse storage, focusing on files and Delta tables.

    Two Types of Assets

    This part describes two types of assets in Lakehouse storage: files and Delta tables.

    When to Use Each

    This part explains when to use files and when to use Delta tables in the context of Lakehouse storage.

    Delta Lake: The Engine Behind the Lakehouse

    This section focuses on Delta Lake as the engine that powers the Lakehouse.

    ACID Transactions

    This part covers ACID transactions in Delta Lake.

    Schema Evolution

    This part covers schema evolution in Delta Lake.

    Time Travel

    This part covers time travel capabilities in Delta Lake.

    Partitioning

    This part covers partitioning in Delta Lake.

    Z-Order

    This part covers Z-order in Delta Lake.

    File Compaction

    This part covers file compaction in Delta Lake.

    Open Format

    This part covers Delta Lake as an open format.

    In the next post in this Lakehouse series, we will move from concepts to implementation and focus on SQL Endpoint, Direct Lake, and building a Lakehouse step by step.

  • What Is a Lakehouse? — And Why It Replaced Data Lakes & Warehouses

    ← Back to Microsoft Fabric — Complete Learning Series

    Lakehouse Foundations · Part 1 of 5

    Why the Lakehouse Became the New Standard

    Modern analytics teams have been stuck between two imperfect options for years: fast but rigid data warehouses, or flexible but chaotic data lakes. Both solved important problems, but neither could deliver a complete, governed, end-to-end analytics platform on its own. This post kicks off a five-part series on the Lakehouse — and how Microsoft Fabric turns the idea of a unified analytics platform into a practical reality.

    The Old World: Lakes vs. Warehouses

    For a long time, organizations had to choose between two very different analytics worlds — and live with the trade-offs.

    Data Lakes

    Data lakes are flexible, scalable, and cost-effective. They are ideal for raw data, machine learning workloads, and handling unstructured assets.

    But when it comes to SQL analytics, strong governance, and reliable BI performance, traditional lakes fall short. The result is often a messy, hard-to-govern environment.

    Data Warehouses

    Data warehouses are structured, governed, and fast. They excel at dimensional modeling and powering business intelligence reports.

    However, they struggle with unstructured data, streaming scenarios, and very large-scale transformations, making them a poor fit for many modern analytics needs.

    This split forced teams into an uncomfortable reality: two storage systems, two compute engines, two governance models, two security layers, two ingestion pipelines, and ultimately, two competing versions of the truth.

    What Is a Lakehouse?

    The Lakehouse emerged to resolve this tension by combining the best properties of both lakes and warehouses in a single architecture.

    A Lakehouse brings together the flexibility of a data lake, the structure of a warehouse, the performance of columnar storage, the openness of Delta Lake, and the governance capabilities of enterprise systems.

    Just as important is what a Lakehouse is not. It is not a warehouse simply sitting on top of a lake. It is not a Spark cluster with SQL bolted on. It is not a BI model that happens to use lake storage. And it is certainly not just a marketing term.

    Instead, a true Lakehouse is a unified architecture where raw files, Delta tables, SQL endpoints, Spark notebooks, BI models, and machine learning workloads all operate on the same data, in the same place, under the same governance model.

    Fabric’s Lakehouse is one of the cleanest implementations of this concept in the industry, bringing these capabilities together in a way that is both powerful and approachable for modern analytics teams.

    The Fabric Lakehouse: What Makes It Different

    Microsoft Fabric takes the Lakehouse idea further than any platform before it. At its core is OneLake, a unified storage layer that serves the entire organization. On top of OneLake, the Fabric Lakehouse brings together storage, compute, governance, and BI in a single experience.

    Key components of the Fabric Lakehouse include:

    • Files — Support for raw data, logs, JSON, CSV, Parquet, images, PDFs, and more.
    • Delta tables — Structured, ACID-compliant, optimized tables that sit directly in OneLake.
    • SQL endpoint — A fully managed SQL engine that queries Delta tables without copying data.
    • Notebooks — PySpark, SQL, Markdown, and ML libraries, all working against the same underlying data.
    • Direct Lake integration — Power BI reads Delta tables directly, eliminating refresh cycles and data duplication.
    • Unified governance — Microsoft Purview provides lineage, labels, and access control in one place.
    • Unified security — Role-based access control is applied consistently across Spark, SQL, BI, and ML workloads.
    • Unified workspaces — Clear Dev/Test/Prod separation, deployment pipelines, and artifact organization.

    The result is not a “Spark-first” or “SQL-first” system. Fabric’s Lakehouse is a unified analytics engine where different personas can work the way they prefer, without fragmenting data or governance.

    Why Lakehouses Matter: The Business Perspective

    Technical details only matter if they move the business forward. Executives and business leaders care about outcomes: faster insights, lower costs, better governance, real-time analytics, reduced complexity, and a unified data strategy. The Lakehouse directly supports all of these goals.

    • Lower costs — Eliminates duplication across separate lake, warehouse, and BI systems.
    • Faster development — One platform, one storage layer, and one security model shorten the path from idea to insight.
    • Real-time analytics — Direct Lake integration removes traditional refresh cycles and copies.
    • Stronger governance — Purview governs data, analytics, and BI assets centrally.
    • Enterprise scalability — Delta Lake supports massive datasets without sacrificing performance or reliability.
    • Unified collaboration — Data engineers, BI developers, and data scientists all work on the same data, instead of maintaining separate pipelines.

    In other words, the Lakehouse is not just a technical evolution. It represents a fundamental shift in how organizations think about data, analytics, and governance across the business.

    What Comes Next in This Series

    This first post set the stage by explaining why the Lakehouse has become the new standard for modern analytics, and how Microsoft Fabric delivers a particularly strong implementation.

    In the rest of this five-part series, we will build on this foundation and explore how the Lakehouse model shapes architecture, development workflows, and analytics experiences across the organization.

    By the end of the series, you will have a clear mental model for how a Lakehouse works in practice and how Fabric can support your data, BI, and AI strategy on a single, unified platform.

    ← Back to Microsoft Fabric — Complete Learning Series

  • Lakehouse Engineering Best Practices & Security in Microsoft Fabric

    Lakehouse Deep Dive, Part 4: Engineering Best Practices and Security

    This is Part 4 of the Lakehouse deep dive series. In this post we focus on two practical topics: how to engineer your Lakehouse for reliable performance and how to set up unified, consistent security across the platform.

    Lakehouse Engineering Best Practices

    The following ten practices help you design Lakehouse workloads that are easier to manage, scale, and optimize over time.

    1. Always Use the Medallion Architecture

    Organize data into Bronze, Silver, and Gold layers so ingestion, cleansing, and serving are clearly separated. This keeps pipelines understandable, supports gradual data refinement, and avoids mixing raw and curated data in the same tables.

    2. Use Delta Lake Everywhere

    Standardize on Delta Lake tables for all Lakehouse storage so you get versioning, reliability, and consistent behavior across ingestion, transformation, and consumption workloads.

    3. Partition Large Tables

    Partition large Delta tables to keep queries efficient and maintenance operations manageable as data volume grows.

    4. Optimize Delta Tables

    Regularly optimize Delta tables so reads and writes stay fast, especially for high-traffic fact tables in your Silver and Gold layers.

    5. Use a Star Schema for the Gold Layer

    Model your Gold layer as a star schema so analytics tools can work with clear fact and dimension tables and you can keep business logic centralized.

    6. Avoid Wide Tables

    Avoid creating very wide tables in the Lakehouse. Keep schemas focused on specific analytical needs rather than combining many unrelated attributes into a single table.

    7. Use Surrogate Keys

    Introduce surrogate keys in your dimensional models so joins are stable and independent of changing source system identifiers.

    8. Use Aggregation Tables

    Create aggregation tables for common reporting patterns so queries do not have to scan detailed fact tables for every request.

    9. Avoid Tiny Files

    Design ingestion and processing so the Lakehouse does not accumulate large numbers of tiny files, which can hurt performance and increase overhead.

    10. Use Deployment Pipelines

    Use deployment pipelines to move Lakehouse changes through environments in a controlled, repeatable way instead of making ad hoc changes directly in production.

    Lakehouse Security: Unified and Consistent

    Security in the Lakehouse should be applied consistently across all entry points, including the Lakehouse itself, the Warehouse, Power BI, notebooks, and pipelines. A unified RBAC (role-based access control) model helps keep permissions aligned for the same users and groups wherever they work.

    RBAC Across the Lakehouse Stack

    Use RBAC to govern access across Lakehouse, Warehouse, Power BI, notebooks, and pipelines so that a user’s role consistently controls what they can see and do, no matter which interface they use.

    The Five Key Security Layers

    A unified security design relies on five complementary layers that work together to protect data and manage access.

    • Workspace roles define who can manage, develop in, or use a workspace at a high level.
    • Item-level permissions control access to specific Lakehouse and Warehouse items.
    • SQL endpoint permissions govern who can query data through SQL endpoints.
    • RLS/OLS in semantic models apply row-level and object-level security for fine-grained control inside Power BI models.
    • Purview sensitivity labels classify and label data so protection and monitoring can follow sensitive information wherever it is used.

    What’s Next in the Series

    The final post in this Lakehouse deep dive series will bring everything together with a look at governance, Dev/Test/Prod strategy, real-world use cases, and a concluding summary of the overall approach.

  • Lakehouse Governance, Dev/Test/Prod Strategy & Real-World Use Cases in Microsoft Fabric

    ← Back to Microsoft Fabric — Complete Learning Series

    Lakehouse Deep Dive, Part 5: Governance, DevOps, and Real-World Use Cases

    This final part of the Lakehouse series brings everything together. It focuses on how governance becomes centralized with Purview integration, how to structure Dev/Test/Prod for a Lakehouse at scale, and how these capabilities show up in seven real-world use cases. It closes by positioning the Lakehouse as the backbone of modern analytics going forward.

    Section 12: Lakehouse Governance — Purview Integration

    Lakehouse governance centers on integration with Purview, which brings together capabilities that were previously scattered across tools and teams. These capabilities include lineage, sensitivity labels, access control, classification, audit logs, and policy enforcement, all unified over Lakehouse assets.

    Lineage Across the Lakehouse

    Lineage tracks how data flows across the Lakehouse, from raw ingestion zones through transformation layers into curated tables, semantic models, and downstream reports. With Purview integration, this lineage is captured consistently for Lakehouse objects, making it possible to understand the impact of changes, trace data quality issues, and support regulatory requirements that depend on end-to-end data traceability.

    Sensitivity Labels and Classification

    Sensitivity labels and data classification can be applied centrally to Lakehouse assets. Classification identifies data domains and categories, while sensitivity labels express how strictly data must be handled. Together, they allow the Lakehouse to consistently tag and protect data, instead of relying on one-off rules in individual tools or datasets.

    Access Control and Policy Enforcement

    Access control is defined and enforced over Lakehouse objects using a unified model. Policies that reference classifications and sensitivity labels can be enforced across data and analytics layers. This means that who can see, query, or export data is governed centrally, rather than being reimplemented separately in each engine or reporting tool.

    Audit Logs and Centralized Governance

    Audit logs capture how Lakehouse data is accessed and governed over time. Combined with lineage, classification, sensitivity labels, and access control, these logs give a full picture of what happened to data and when. Governance is no longer scattered across multiple systems and manual processes; it is expressed once and applied consistently over the Lakehouse.

    Section 13: Lakehouse Dev/Test/Prod Strategy

    A Lakehouse Dev/Test/Prod strategy relies on clear separation of environments, repeatable deployment pipelines, and consistent rules for how assets move from development into production. The core best practices include separate workspaces, deployment pipelines, naming conventions, RBAC roles, parameterized pipelines, version control for notebooks, and semantic model deployment rules.

    Separate Workspaces and Deployment Pipelines

    Dev, Test, and Prod are implemented as separate workspaces. Deployment pipelines move Lakehouse assets across these workspaces in a controlled, repeatable way. This separation reduces risk, supports validation before changes reach production, and provides a clear path for promoting features from development to stable environments.

    Naming Conventions and RBAC Roles

    Naming conventions make Lakehouse assets understandable and predictable across environments. RBAC roles control who can change, deploy, or consume assets in Dev, Test, and Prod. Together, naming and RBAC make it easier to manage large Lakehouse estates and to keep responsibilities clear between engineering, operations, and business users.

    Parameterized Pipelines and Version-Controlled Notebooks

    Parameterized pipelines allow the same logic to run in multiple environments by switching parameters, instead of maintaining separate pipeline definitions. Version control for notebooks brings Lakehouse development in line with software engineering practices, enabling change history, collaboration, and controlled releases of transformation logic.

    Semantic Model Deployment Rules

    Semantic model deployment rules define how models are promoted between Dev, Test, and Prod. These rules cover which changes are allowed, how they are validated, and how they are rolled out to consumers. In the Lakehouse context, this ensures that semantic layers stay in sync with underlying tables and pipelines as they progress through environments.

    Section 14: Real-World Lakehouse Use Cases

    Lakehouse capabilities come together in real-world scenarios. Seven representative use cases illustrate how one Lakehouse, with unified governance and Dev/Test/Prod practices, supports enterprise data lake modernization, real-time analytics, operational visibility, regulatory reporting, customer intelligence, machine learning, and IoT workloads.

    Enterprise Data Lake Modernization

    Enterprise Data Lake Modernization uses the Lakehouse to consolidate existing data lakes, warehouses, and marts onto a single platform. The unified storage format and governance layer allow legacy data platforms to be modernized without losing control over security, lineage, and access policies.

    Real-Time Sales Dashboards

    Real-Time Sales Dashboards rely on the Lakehouse to land and process sales events quickly while keeping them available for reporting on current performance. With a single Lakehouse, real-time and historical sales data share the same storage format and governance model.

    Supply Chain Visibility

    Supply Chain Visibility brings together data from logistics, inventory, orders, and partners into the Lakehouse. With one governance layer, teams can monitor movement, stock levels, and fulfillment status without duplicating data and controls across multiple systems.

    Financial Reporting

    Financial Reporting uses the Lakehouse to centralize financial data in one storage format, with one security model applied consistently. This supports reporting and analytics that depend on strict control over lineage, auditability, and policy enforcement while keeping data accessible to authorized users.

    Customer 360

    Customer 360 aggregates customer data into Lakehouse tables that share a single governance layer. Lineage, sensitivity labels, access control, and classification help manage the mix of personally identifiable data and behavioral signals, while still giving a unified view of customers.

    ML Feature Store

    An ML Feature Store built on the Lakehouse exposes features in the same storage format and governance model as analytical tables. Version-controlled notebooks, parameterized pipelines, and semantic model deployment rules support how features are engineered, validated, and promoted through Dev, Test, and Prod.

    IoT Analytics

    IoT Analytics uses the Lakehouse to store and analyze device data at scale. Real-time and batch processing share the same Lakehouse, so governance, access control, and audit logging apply uniformly across sensor streams, curated aggregates, and downstream dashboards.

    Conclusion: The Lakehouse Is the Backbone of Modern Analytics

    The Lakehouse acts as the backbone of modern analytics by converging data, governance, and operations into a single platform. It delivers one lake, one security model, one governance layer, one storage format, and one experience for data engineering, analytics, and machine learning teams.

    One lake simplifies where data lives. One security model and one governance layer standardize how data is protected, audited, and controlled. One storage format streamlines how data is ingested, transformed, and queried. One experience aligns how teams develop, test, deploy, and consume data products. Together, these Lakehouse principles support the next wave of analytics initiatives that rely on consistency, trust, and scale.

    ← Back to Microsoft Fabric — Complete Learning Series

  • Easy way to dynamically fetch the latest file from OneDrive or SharePoint to Power BI – 1 Way

    Easy way to dynamically fetch the latest file from OneDrive or SharePoint to Power BI – 1 Way

    Dynamically connect/upload/fetch/access an excel file from OneDrive or SharePoint using Power BI (Power Query)

    We all know how to connect to a file (let’s say excel.xlsx) residing in OneDrive or SharePoint, but in this post, we will go over the steps that will fetch the latest file from a designated folder.

    You may ask. That why we may want to do this? Well, there are several reasons. One such use case is when your end-user uploads (dumps) an data file in a particular location at a pre-defined upload cadence, and a Power BI report must fetch that latest file.

    One brute force method is always to change the connection string point to that latest file. However, you will have to reconnect or point to the right file every single time. Tedious, manual, and brute force, but this is good when you want to do unit testing.

    Or if you want to do this task dynamically then please read on.

    For those who want a quick explanation then here it goes

    1. Connect to the desired sheet
    2. Modify the connection to SharePoint.Contents (I personally find this better, here is why)
    3. Create the query parameters based on your file and folder structure
    4. Sort by on date modified or date accessed (your choice).
    5. The above choice depends on how this sheet is used (is it modified or a new copy is uploaded every time)
    6. Filter the rows to .xslx extension
    7. Keep the top row
    8. Filter for the hidden files
    9. Invoke a custom function
    10. And that’s it. You have done it

    Below is my final result image.