Fabric Metadata Driven Framework July 2026 Release Notes

Fabric Metadata Driven Framework July 2026 Release Notes

by | Jul 16, 2026 | FMD Framework

Fabric Metadata‑Driven Framework (FMD)

Erwin

by Erwin | Jul 16, 2026

Table of Contents

Microsoft Fabric Metadata Driven Framework July 2026 Release

The Microsoft Fabric Metadata Driven Framework (FMD Framework) continues to evolve rapidly, driven by real-world customer implementations and an amazing open-source community. This July 2026 release focuses on improved lineage and governance, simplified deployment automation, stronger reliability, and enhanced security across the framework.

Before diving into the details, I would like to give special recognition to one contributor in particular.

Special Thanks to Matthias Falland

This release would not have been possible without the incredible contributions from Matthias 

A large number of improvements in this release from deployment automation and security hardening to pipeline reliability and lineage enhancements, were contributed, reviewed and refined through their efforts.

Open-source projects thrive because of people who are willing to invest their expertise and time to make the platform better for everyone. The quality, attention to detail, and commitment to enterprise-grade reliability demonstrated in these contributions have significantly strengthened the FMD Framework.

A sincere thank you for helping make FMD more robust, secure, and adoption-ready for organizations building modern data platforms on Microsoft Fabric.

What's New in the Microsoft Fabric Metadata Driven Framework July 2026 Release

Enhanced Purview Lineage Integration

Following the recent introduction of the Fabric-to-Purview Lineage Extractor, several improvements have been implemented to simplify lineage management and make deployments more reliable.

Folder-Based Lineage Processing

One of the most requested enhancements was changing lineage extraction from a file-based approach to a folder-based approach.

Benefits:

  • Simplified landing zone configuration
  • Reduced maintenance effort
  • More logical alignment with real-world data lake architectures
  • Improved support for complex ingestion scenarios

This change allows FMD to automatically process all relevant files within a designated folder instead of requiring explicit file references.

Improved Workspace Reference Handling

The lineage extractor now correctly references Fabric Workspace identifiers through deployment placeholders, making multi-environment deployments considerably simpler.

Benefits:

  • Easier Dev/Test/Prod deployments
  • Reduced manual configuration
  • Improved portability between tenants

Simplified Deployment and Onboarding

A major focus of this release was reducing deployment complexity.

Automated Fabric SQL Connection Creation

The Microsoft Fabric Metadata Driven Framework now supports automated Fabric SQL connection creation. You can now automatically create the CON_FMD_FABRIC_SQL connection using a Service Principal.

Why this matters

Previously, administrators needed to manually create and configure the connection before deployment.

Now FMD can:

  • Create the connection automatically
  • Configure authentication
  • Reduce post-deployment manual steps
  • Accelerate onboarding

This significantly improves first-time installations.

Improved Key Vault Integration

A new configuration option enables SQL connections to leverage Azure Key Vault.

Benefits

  • Centralized credential management
  • Better security posture
  • Easier credential rotation
  • Reduced operational risk

This aligns FMD more closely with enterprise security and governance standards.

Reliability Improvements Across Data Pipelines

This release contains several reliability-focused enhancements that improve monitoring, troubleshooting, and operational transparency.

Better Failure Detection

Multiple pipelines now correctly report failures instead of reporting successful execution when an underlying process fails.

Enhancements include:

  • PL_FMD_LOAD_ALL
  • Landing Zone processing
  • Landing Zone audit activities
  • Pipeline logging improvements

Operational impact

Data engineers and platform teams can now:

  • Detect issues faster
  • Trust audit results
  • Improve monitoring accuracy
  • Reduce troubleshooting time

Improved Pipeline Correlation Tracking

Pipeline executions now receive improved PipelineParentRunGuid fallback logic.

Extended support was added for:

  • Notebook executions
  • Bronze processing
  • Silver processing

This improves observability and end-to-end execution tracking.

Watermark Synchronization Improvements

An issue was resolved where watermark advancement could occur before queue insertion completed.

The process is now serialized correctly to ensure:

  • Better incremental load reliability
  • Reduced chance of missed records
  • Improved consistency during high-volume processing

Data Quality and Transformation Improvements

Several improvements have been made to metadata-driven transformations.

Improved Hash Generation

Stable Primary Key Hashes

Hashed primary keys are now generated independently of source column order.

Benefits:

  • Consistent hash generation
  • Reduced risk during schema changes
  • Improved reproducibility

Better Change Detection

Primary key columns are now excluded from HashedNonKeyColumns calculations.

This improves:

  • Change tracking accuracy
  • Delta detection reliability
  • Incremental processing performance

DACPAC Validation

Build pipelines now verify that:

  • DACPAC artifacts match the SQL source project
  • SQL changes are correctly included
  • Deployment packages remain synchronized

Additionally:

  • DACPAC generation has been automated
  • Deployment consistency has improved
  • Release quality has increased

Additional Fixes

This release also includes numerous bug fixes and quality-of-life improvements:

  • Fixed StartCopyActivity typo affecting ADLS and ADF visibility
  • Added missing invoke_fabric_api_request implementation
  • Corrected deployment guide sequencing
  • Improved demo data deployment
  • Enhanced OneLake configuration deployment
  • Updated Lakehouse assets and DACPAC packaging
  • Improved namespace handling to prevent truncation issues

Community Contributions

A special thank you goes to Matthias Falland  for a significant number of high-quality contributions in this release. These improvements help make FMD more reliable, secure, and easier to deploy across enterprise environments.

Open-source collaboration continues to play a crucial role in making FMD the leading metadata-driven framework for Microsoft Fabric.

Conclusion

This July release is less about introducing flashy new features and more about something equally important: enterprise readiness.

The improvements delivered in this update strengthen the framework in four critical areas:

✅ Better Purview integration and lineage management
✅ Simplified deployments and onboarding
✅ Improved operational reliability and monitoring
✅ Stronger security and governance controls

For organizations building large-scale Microsoft Fabric implementations, these enhancements further reduce deployment complexity while increasing trust in metadata-driven automation.

The FMD Framework continues its mission of helping organizations build scalable, governed, and AI-ready data platforms on Microsoft Fabric.

New to the Microsoft Fabric Metadata Driven Framework?

 Learn more about the framework architecture, deployment model, and features here:

 

The Microsoft Fabric Metadata Driven Framework continues to help organizations standardize data platform delivery, automate Microsoft Fabric deployments, improve governance, and accelerate AI-ready architectures. With every release, the framework becomes more reliable, secure, and easier to adopt for enterprise-scale Microsoft Fabric implementations.

 

GitHub Repository
👉FMD_FRAMEWORK

Hit Subscribe to get future release notes delivered straight to your inbox!

Latest FMD Releases

Latest Posts

Categories

Feel free to leave a comment

Reassigning Microsoft Fabric Capacities in Bulk: Don’t Let an Expiring Trial Catch You by Surprise

Reassigning Microsoft Fabric Capacities in Bulk: Don’t Let an Expiring Trial Catch You by Surprise

by | Jul 14, 2026 | Blogs

Erwin

by Erwin | Jul 14, 2026

Table of Contents

Avoid Losing Fabric Items When a Trial Expires: Bulk Reassign Workspaces Between Capacities Using Fabric CLI

With the summer holiday season approaching, many organizations are running Microsoft Fabric workloads on trial capacities that were originally created for proof-of-concepts, workshops, or development activities. What often gets overlooked is that Fabric trial capacities eventually expire, and when they do, the consequences can be significant. According to Microsoft Fabric community guidance, you have only seven days after trial expiration to reassign your workspaces to an active capacity. After that retention period, non-Power BI Fabric items are removed according to the retention policy.

For a tenant with a handful of workspaces, manually reassigning capacities might be manageable. But what if you need to migrate dozens or even hundreds of workspaces from Capacity A to Capacity B?
Fortunately, there is an easy way to automate this process.

Why Reassign Capacities?

There are several common scenarios:

  • A Fabric Trial capacity is about to expire.
  • You purchased a new Fabric capacity and want to move workloads.
  • You're consolidating capacities to reduce costs.
  • You're separating development, test, and production workloads.
  • You're moving workspaces to a larger SKU due to increased usage.

Whatever the reason, workspace reassignment is a straightforward administrative task that can be automated through the Fabric CLI and Fabric APIs.

The Hidden Risk of Trial Capacities

Many organizations start their Fabric journey on a trial capacity. It works great for evaluations, hackathons, and pilot projects. However, when the trial expires, the clock starts ticking.
Fabric Trail Expire
Microsoft states that after trial expiration, you have a seven-day window to save your Fabric content by assigning the affected workspaces to an active Fabric capacity. If you don't migrate the workspaces assigned to your Fabric trial capacity before your free Fabric trial capacity expires, the workspaces will be moved to Power BI with license mode Pro and you will not be able to use Fabric (non-Power BI) items. Fabric items not moved to a Power BI Premium or Fabric capacity within 7 days after your trial ends may be permanently deleted. If you have Power BI items, they will continue to exist in the workspace. Items that you created in other workspaces not assigned to your Fabric trial capacity will be unaffected.

I've seen customers develop:

  • Lakehouses
  • Notebooks
  • Data Pipelines
  • Dataflows Gen2
  • Semantic Models
  • Warehouse solutions

...only to discover during a holiday period that their trial is expiring.

My advice: don't wait until the last day.

Bulk Migration with Fabric CLI

Instead of opening every workspace manually, you can automate the entire process.

The approach is simple:

  1. Enumerate all Fabric workspaces.
  2. Identify the current capacity.
  3. Optionally filter specific workspaces.
  4. Assign them to the target capacity.
  5. Create a migration report.
  6. Helps you avoid manual workspace-by-workspace administration

tasks = []

filter_set = (
    {w.lower() for w in filter_workspaces}
    if filter_workspaces
    else None
)

workspaces = get_workspaces()

for ws in workspaces["result"]["data"]:

    workspace_name = ws.get("name", "").removesuffix(".Workspace")
    capacity_name = ws.get("capacityName", "")

    # Optional workspace filter
    if filter_set and workspace_name.lower() not in filter_set:
        continue

    # Skip unassigned workspaces
    if capacity_name == "N/A":
        continue

    if assign_capacity_to_all_fabric_workspaces:

        if capacity_name != target_capacity:

            print(f"Moving {workspace_name}  from {capacity_name} to {target_capacity}" )
            result = assign_capacity(workspace_name,target_capacity )
            tasks.append({"Workspace": workspace_name,"Source Capacity": capacity_name,"Target Capacity": target_capacity,"Remarks": result})

        else:
            print(f"{workspace_name} no action needed, capacity already assigned")
            tasks.append({"Workspace": workspace_name,"Source Capacity": capacity_name,"Target Capacity": target_capacity,"Remarks": "Capacity already assigned"})
 
    else:

        if capacity_name == source_capacity:
                        
            print(f"Moving {workspace_name}  from {source_capacity} to {target_capacity}" )
            result = assign_capacity(workspace_name,target_capacity )
            tasks.append({"Workspace": workspace_name,"Source Capacity": capacity_name,"Target Capacity": target_capacity,"Remarks": result})

        else:

            print(f"{workspace_name} skipped current capacity: {capacity_name}" )
            tasks.append({"Workspace": workspace_name,"Source Capacity": capacity_name,"Target Capacity": target_capacity,"Remarks": "Skipped - not on source capacity"})

Check out the script on GitHub and adapt it to your environment:

Check out my GitHub repository for the complete migration script.

Fabric_Tooling/NB_WORKSPACE_CHANGE_CAPACITY

Whether you're cleaning up trial capacities, consolidating environments or moving to a larger Fabric SKU, automation can save a lot of time and reduce the risk of missing a critical workspace.

Why Automation Matters

I've noticed many Fabric environments that started as small experiments and quickly grew into business-critical platforms.

A workspace that started as:

"Let's just test Fabric for a few days"

Can suddenly contain:

  • Production pipelines
  • Business reporting
  • Data engineering workloads
  • Governance processes

When a trial capacity approaches expiration, manually managing dozens of workspaces becomes error-prone.

Automating the migration process provides:

  • Repeatability
  • Traceability
  • Faster execution
  • Lower risk
  • Full reporting

Final Thoughts

If you're using Microsoft Fabric Trial capacities today, take a few minutes to check:

  • Which workspaces are assigned to the trial.
  • When the capacity expires.
  • Whether a long holiday period overlaps with the expiration date.

Remember that Microsoft provides only a limited grace period after trial expiration to save your Fabric items by moving the workspace to an active capacity.

The good news is that moving workspaces from Capacity A to Capacity B can be fully automated. A simple Fabric CLI or REST API script can handle the migration in minutes and help you avoid an unpleasant surprise when you return from vacation.

Tip: Even if you're not currently running a trial, keeping an automated capacity migration script in your Fabric toolbox is a great operational practice. Sooner or later, you'll need it for a capacity upgrade, consolidation, or tenant migration.

Latest Posts

Categories

Feel free to leave a comment

Fabric Metadata Driven Framework July 2026 Release Notes

Bringing Column-Level Lineage from Microsoft Fabric to Microsoft Purview with FMD

by | Jul 8, 2026 | FMD Framework, Microsoft Purview

Fabric Metadata‑Driven Framework (FMD)

Erwin

by Erwin | Jul 8, 2026

Table of Contents

One of the questions I receive most often from customers is:

"How can we get column-level lineage from Microsoft Fabric into Microsoft Purview?"

Microsoft Purview can scan Microsoft Fabric and visualize item-level lineage, but column-level lineage for Lakehouse transformations is still not available out of the box. This has been one of the most requested governance capabilities from customers. Today, FMD closes a large part of that gap by automatically generating and publishing column-level lineage to Microsoft Purview.

Over the past few weeks, I have been working on a solution during evenings and weekends to bridge that gap. Today, I'm excited to share that the Fabric Metadata-Driven Framework (FMD) now includes functionality to automatically extract column-level lineage from Fabric Lakehouses and publish it directly into Microsoft Purview.

Even better, I've also made the core lineage extraction capabilities available in a standalone repository so the broader community can benefit from it as well.

Why Column-Level Lineage Matters

Table-level lineage is useful, but it only tells part of the story.

Most organizations need answers to questions such as:

  • Which source column feeds this KPI?
  • Where does a specific attribute originate?
  • What happens if I rename a column upstream?
  • Which reports and data products are impacted by a change?
  • How does data move through my Bronze, Silver, and Gold architecture?

Without column-level lineage, answering these questions often requires manually reviewing notebooks, pipelines, SQL scripts, mapping documents, and transformation logic.

As data platforms grow, this quickly becomes difficult to manage.

The Current Challenge

Microsoft Fabric provides powerful capabilities for building modern data platforms.

Microsoft Purview provides enterprise-grade governance and lineage visualization.

The challenge is that there is currently no out-of-the-box solution that automatically generates column-level lineage for Fabric Lakehouse transformations. While metadata and item-level lineage are supported, column-level relationships for Lakehouse processing are not automatically available today

Many customers have asked for:

  • End-to-end traceability
  • Better impact analysis
  • Improved governance
  • Regulatory compliance support
  • Automated documentation
  • Visibility into how columns move across the platform

This is exactly the problem this new functionality aims to solve.

The FMD Approach

The new functionality leverages metadata already available within the Fabric Metadata-Driven Framework.

Because FMD already knows:

  • Source entities
  • Target entities
  • Data movement patterns
  • Transformation metadata

it becomes possible to generate lineage automatically rather than documenting it manually.

The lineage extraction process identifies relationships between source and target columns and publishes them into Microsoft Purview, allowing organizations to visualize and govern lineage using familiar Purview capabilities.

The result is significantly richer lineage visibility across your Fabric environment.

 Column-Level Lineage from Microsoft Fabric to Microsoft Purview

Column-Level Lineage

Not Every Lineage Scenario Can Be Automated

Let's be realistic.

No lineage solution can automatically solve every possible lineage scenario.

Organizations often have:

  • Complex business logic
  • Custom transformations
  • External applications
  • Manual enrichment processes
  • Proprietary calculation engines

These scenarios may still require manual lineage definitions.

However, the good news is that the majority of a typical Lakehouse architecture follows predictable patterns that can be automated.

With this solution you can automatically generate lineage for:

  • Landing Zone to Bronze
  • Bronze to Silver
  • Renamed Tables
  • Metadata-driven transformations
  • Lakehouse-to-Lakehouse relationships
  • Shortcut-based lineage scenarios

This means that for many organizations, most of the lineage effort can be automated, while the remaining exceptions can simply be maintained manually in Purview.

Rather than documenting everything by hand, you automate the majority and focus only on the edge cases.

A Practical Example

Consider a common Fabric architecture:

Landing Zone → Bronze → Silver 

Landingzone Bronze Silver Shortcut in Gold
Filename wwi.v_customers wwi.customers dbo.customers

Traditional lineage often shows relationships between the same tables.

With the new FMD lineage extraction process, it becomes possible to capture and publish the actual table and schema relationships so users can understand exactly how data elements move through the platform.

This dramatically improves:

  • Impact analysis
  • Data discovery
  • Governance
  • Auditability
  • Trust in analytical outputs

Not Using FMD? You Can Still Use It

While this capability is fully integrated into FMD, I also wanted to make it available to the wider community.

That's why I created a separate repository containing a standalone notebook that can be used independently from FMD.

The notebook can be adapted to:

  • Custom Fabric implementations
  • Other metadata-driven frameworks
  • Lineage enrichment scenarios
  • Shortcut lineage implementations
  • Custom source-to-target mapping scenarios

Repository:

Fabric to Purview Lineage extractor

The repository contains everything needed to get started and can serve as a foundation for building your own lineage generation process.

Already using FMD?

If you're already using the Fabric Metadata-Driven Framework, getting started is very easy.

Simply:

  1. Download the latest FMD version or
  2. Run the NB_SETUP_FMD notebook again to deploy the latest components.

If you choose not to update to the latest version, make sure to add the following parameter to your existing configuration:

purview_account_name = "val_purview_account_name"

This parameter is required by the new lineage extraction functionality when publishing lineage into Microsoft Purview.

Configuring Authentication

To publish lineage into Microsoft Purview, the notebook requires a Service Principal with the appropriate permissions in both Microsoft Fabric and Microsoft Purview.

Important: Before running the lineage extractor, configure a Service Principal with access to both Microsoft Fabric and Microsoft Purview. See the README for the required permissions and setup instructions.

The repository README includes step-by-step guidance for:

  • Creating a Service Principal
  • Granting permissions in Fabric
  • Granting permissions in Purview
  • Configuring authentication
  • Running the lineage extraction notebook

Before getting started, make sure to review the setup instructions in the repository:

These improvements further strengthen FMD as a platform‑engineering foundation for Microsoft Fabric.

Built for the Community

This feature started as a side project driven by customer demand.

Time and again I heard the same request:

"We love Fabric and Purview, but we need better column-level lineage."

Instead of waiting for the capability to appear natively, I decided to see how far we could get using metadata, automation, and the Microsoft Purview APIs.

The result is a practical solution that helps organizations significantly improve governance visibility while leveraging investments they have already made in Microsoft Fabric and Microsoft Purview.

Final Thoughts

This solution won't automate every possible lineage relationship—and that's okay.

What it does do is automate a very large portion of your Lakehouse architecture, dramatically reducing the effort required to maintain lineage information.

For most organizations, that means:

  • Less manual documentation
  • Better governance
  • Faster impact analysis
  • Increased trust in data
  • Greater visibility across the platform

After several weeks of development, I'm happy to finally share this capability with the community.

I hope it helps close an important governance gap and enables more organizations to build truly governed, metadata-driven data platforms on Microsoft Fabric.

As always, feedback, ideas, and contributions are welcome.

Happy governing!

Stay Connected

GitHub Repository:

👉FMD_FRAMEWORK

FMD Framework:

👉Main FMD Page

WIKI:

👉FMD_FRAMEWORK Wiki

Hit Subscribe to get future release notes delivered straight to your inbox!

Latest FMD Releases

Latest Posts

Categories

Feel free to leave a comment

My first experience: Building a Fabric App

My first experience: Building a Fabric App

by | Jun 7, 2026 | Microsoft Fabric

Erwin

by Erwin | Jun 7, 2026

My first experience: Building a Fabric App on top of my FMD Framework

 

At Microsoft Build 2026, Microsoft introduced Rayfin a major step forward in how we build applications on Microsoft Fabric.

If you’ve been working in the Fabric ecosystem, this is big.

Rayfin is an open‑source SDK + CLI that lets you define and deploy a complete, governed application backend directly on Microsoft Fabric.

No more stitching together databases, APIs, authentication, and governance yourself.

Instead:

You define your backend in code → Rayfin provisions everything → Fabric runs it with enterprise-grade governance by default.

So when Rayfin was introduces I couldn’t resist trying it out immediately.

So I did what I always do…

I plugged it into something real.

I built a simple web configuration portal on top of my Fabric Metadata-Driven (FMD) Framework to manage metadata not through notebooks or pipelines, but through a clean UI.

What I built (in a few hours)

I created a lightweight metadata management app:

  • A web interface to fill metadata through a portal
  • A light master data app using static tables
  • But with the flexibility to:
    • Add new tables
    • Add new columns
    • Extend the model yourself

Basically:

A dynamic metadata-driven admin UI on top of Fabric

Was it production-ready?
No, just a mockup.

Was it powerful?

Absolutely.Fabric web app

 What surprised me most

The speed.

Normally, building something like this requires:

  • Backend APIs
  • Database configuration
  • Authentication setup
  • Access policies
  • Deployment pipelines

With Rayfin?

None of that was manual anymore

I just:

  1. Defined the data model
  2. Added some logic
  3. Ran the deployment

And Fabric handled the rest:

  • Database
  • APIs
  • Auth
  • Governance

This aligns exactly with what Rayfin is designed to do:

Define your backend in code and deploy it directly to Fabric as a governed app.

What else did I try

I build a master data management web app mockup, just as a try.

The master data management web app combines predefined tables with full flexibility to extend the model yourself. Core entities like products, categories, suppliers, and customers are available out of the box, providing a solid starting point for managing standard master data. At the same time, the app introduces a powerful capability: users can create custom tables and add new columns dynamically, effectively evolving the data model without needing to redeploy or change backend code.

Fabric web app master data

 

Just try outs, but amazing fast. I will explore the Fabric app the coming weeks/months much more.

The essential Rayfin docs (bookmark this)

If you want to go hands-on, these are the core docs you’ll actually use:
Get Started — Create your first Fabric App

Create your first Fabric apps project

Deploy to Microsoft Fabric

Deploy a Fabric App to Fabric

Read & Write Data with GraphQL

Read and write data with GraphQL in Fabric Apps

Configure Authentication

fabric_webb_app_master data Configure Fabric SSO authentication for your Fabric app

Understand the Project Structure

Fabric Apps project structure

Rayfin CLI Reference

Rayfin CLI reference

Connect to a Semantic Model (Data App Template)

 

 

Latest Posts

Categories

Feel free to leave a comment

Fabric Metadata Driven Framework July 2026 Release Notes

Fabric Metadata Driven Framework update May 2026

by | May 28, 2026 | FMD Framework

Fabric Metadata‑Driven Framework (FMD)

Erwin

by Erwin | May 28, 2026

Table of Contents

The May update of the Fabric Metadata‑Driven (FMD) Framework focuses on security simplification, identity best practices, and improved data consistency in hashing logic. This release builds on the continued evolution towards native Microsoft Fabric patterns, reducing complexity while improving reliability across Bronze and Silver layers.Following Microsoft Fabric advancements, this release removes the dependency on Service Principals for optional Key Vault access.

Workspace Identity as the standard

 What’s changed

Service Principal support for optional Key Vault scenarios has been removed
Workspaces now use Workspace Identity as the default authentication model

What this means

Cleaner and more secure setup aligned with Fabric best practices
No need to manage additional secrets or credentials
Reduced operational

This aligns directly with the broader shift in Fabric towards Workspace Identity for notebooks and pipelines

Seamless Integration with Notebooks & Data Pipelines

Workspace Identity is now fully supported across:

Notebook connections
Data Pipeline connections
Key improvement
Unified authentication model across orchestration and execution layers

Required action

To enable secure Key Vault access:

  • Add the Workspace Identity to a security group
  • Assign the security group to Key Vault with role:
    Key Vault Secrets User
  • This ensures secure and controlled access without introducing additional credentials.

Improvements in Hashing Logic (Bronze & Silver)

Several fixes have been introduced to improve data consistency and correctness in hashing behavior.

Bronze Layer

HashedPKColumn is now excluded when generating the hash for HashedNonKeyColumns

Silver Layer

HashedNonKeyColumns is excluded from its own hash generation
RecordLoadDate is excluded from hash calculations

Notebook Stability Fixes

Additional fixes were applied to improve reliability when loading and executing Bronze and Silver notebooks:

Improved notebook loading behavior
Better handling of edge cases during execution

These changes contribute to more predictable and stable pipeline runs, continuing the focus on robustness seen in previous releases

Community Contribution

Special thanks to Nick De Zeeuw for identifying and raising the hashing issue, a great example of how community feedback directly improves the framework.

These improvements further strengthen FMD as a platform‑engineering foundation for Microsoft Fabric.

Bug Fixes & Community Contributions

A huge thank‑you to the community for reporting issues and submitting pull requests!
This release includes:

  • Minor bug fixes
  • Stability improvements
  • Quality‑of‑life enhancements informed by your feedback
  • Your contributions directly shape and refine the framework.

Stay Connected

GitHub Repository
👉FMD_FRAMEWORK

Hit Subscribe to get future release notes delivered straight to your inbox!

Latest FMD Releases

Latest Posts

Categories

Feel free to leave a comment