community contest
15 TopicsTurning Supply Chain Data into AI-Powered Supplier Risk Insights with Microsoft Fabric
Supply chain teams often have plenty of data—but the real challenge is turning that data into actionable insights. Delivery delays, quantity mismatches, quality problems, supplier remarks, and customer feedback are usually available in different columns, but understanding the overall supplier situation often requires manual analysis. In this blog, I’ll walk through a practical Microsoft Fabric notebook solution that combines traditional supply-chain KPIs with Fabric AI Functions to enrich supplier-order data with AI-generated insights. The solution uses: Microsoft Fabric Lakehouse Fabric Notebook PySpark Fabric AI Functions through synapse.ml.spark.aifunc Delta tables Rule-based risk classification The final output brings operational metrics and AI insights together into a single business-facing dataset. The Business Problem Imagine a procurement or supply-chain team receiving thousands of supplier orders. For every order, they may want to answer questions such as: Was the order delivered on time? How much quantity was actually delivered? Was there a quantity shortage? What was the defect rate? What issue was reported by the supplier? Is the customer's feedback positive or negative? What exactly went wrong? Can supplier remarks be standardized into English? What is the potential supplier risk? Which suppliers require attention? Traditional calculations can answer some of these questions, but unstructured text such as supplier remarks and customer feedback requires additional processing. This is where Fabric AI Functions can complement traditional PySpark transformations. Solution Overview The notebook follows an end-to-end processing flow: CSV in Fabric Lakehouse ↓ PySpark ↓ Data Preparation ↓ Traditional Supply Chain KPIs ↓ Fabric AI Functions ↓ ┌─────────────────────────────┐ │ Issue Classification │ │ Customer Sentiment │ │ Information Extraction │ │ Translation │ │ Supplier Risk Analysis │ └─────────────────────────────┘ ↓ Deterministic Risk Rules ↓ Final Business Dataset ↓ Delta Table The resulting Delta table is: supply_chain_ai_analysis The implementation is based on a Fabric notebook using PySpark and synapse.ml.spark.aifunc. 1. Preparing the Source Data The source data is stored as a CSV file in the Fabric Lakehouse. The dataset contains information such as: Order ID Order date Supplier Material Plant Ordered quantity Delivered quantity Promised delivery date Actual delivery date Quality score Defect quantity Shipment mode Supplier remarks Customer feedback The notebook reads the CSV using Spark's CSV reader with header-based column names and schema inference. One important point is that the demonstration notebook limits the working dataset to 25 records before the main transformations. This is useful while developing and testing the solution, but it should not be treated as production logic. For a production implementation, the limit should either be removed or converted into a configurable parameter. 2. Preparing the Date Columns The source dates are stored in dd-MM-yyyy format. The notebook converts: Order_Date Promised_Date Actual_Delivery_Date from strings into Spark date values. This is important because the delivery calculations depend on actual date arithmetic. For example: Delivery Delay = Actual Delivery Date - Promised Delivery Date The implementation uses PySpark's datediff() function for this calculation. One important production consideration is that the source date format must be consistent. If the incoming data uses a different format, the conversion can result in null dates. 3. Calculating Traditional Supply Chain KPIs Before applying AI, the notebook calculates traditional operational metrics. This is an important design principle: Use deterministic calculations for measurable business metrics and AI where unstructured information needs interpretation. Delivery Delay The notebook calculates: Delivery_Delay_Days = datediff(Actual_Delivery_Date, Promised_Date) The result is then converted into a delivery-performance category: Delay Performance ≤ 0 days On Time ≤ 3 days Slight Delay > 3 days Major Delay These calculations provide an objective measurement of delivery performance. Quantity Fulfillment The notebook calculates: Quantity_Variance = Delivered_Qty - Ordered_Qty and: Quantity_Fulfillment_Percentage = Delivered_Qty / Ordered_Qty × 100 This allows the business to understand whether suppliers delivered the complete ordered quantity. Defect Rate The quality calculation is: Defect_Rate_Percentage = Defect_Qty / Ordered_Qty × 100 Together, delivery performance, quantity fulfillment, and defect rate provide the traditional operational view of supplier performance. 4. Bringing AI into the Pipeline Once the traditional metrics are calculated, the notebook applies Fabric AI Functions to the text-based fields. The AI enrichment includes: Issue classification Customer sentiment analysis Information extraction Translation Supplier risk analysis The implementation uses: synapse.ml.spark.aifunc and applies functions such as: classify() analyze_sentiment() extract() translate() generate_response() This is where the pipeline moves beyond simple KPI calculation. 5. AI-Based Supplier Issue Classification Supplier remarks can contain different types of problems. For example, a remark might indicate: A late delivery A quality problem A logistics problem A quantity problem No significant issue The notebook classifies supplier remarks into five predefined categories: Late Delivery Quality Issue Logistics Issue Quantity Issue No Issue The result is stored in: AI_Issue_Category This converts unstructured supplier remarks into a structured business attribute. Instead of manually reviewing every remark, a business user can now filter or group orders based on the identified issue category. 6. Understanding Customer Sentiment Customer feedback provides another important signal. For example, operational metrics may show that an order was delivered only slightly late, but the customer feedback could reveal dissatisfaction. The notebook sends: Customer_Feedback to the AI sentiment function. The resulting value is stored in: AI_Customer_Sentiment This provides another dimension for understanding supplier performance. 7. Extracting Structured Problems from Supplier Remarks Classification tells us what type of issue exists. But sometimes we also want to know what actually happened. The notebook therefore extracts three types of information from supplier remarks: Delay_Reason Quality_Problem Quantity_Problem These extracted values are then consolidated into: AI_Extracted_Information Only populated categories are included in the consolidated output. This is useful because the original supplier remark might be a complete sentence or paragraph, whereas the extracted information provides a more structured representation. 8. Translating Supplier Remarks Supplier remarks may not always be written in English. The notebook uses the Fabric AI translation function to translate supplier remarks into English. The result is stored as: AI_English_Remark The target language is explicitly set to English. This can help organizations standardize text for centralized analysis when suppliers operate across different regions or languages. 9. Generating a Supplier Risk Assessment The next step is generating a short natural-language supplier risk assessment. The notebook creates a prompt using: Supplier_Name Delivery_Performance Quality_Score The AI function is asked to generate a concise, two-sentence supplier risk assessment that mentions: The main risk One recommended action The output is stored in: AI_Supplier_Risk_Analysis This is particularly useful for management-facing analysis because a user does not have to interpret every KPI individually. Instead, the system can provide a short narrative explaining the potential concern. 10. Keeping Final Risk Classification Deterministic One of the most important design decisions in this solution is that the final Overall_Risk is not generated by AI. Instead, the notebook uses deterministic PySpark rules. The implemented logic is: High Risk Delivery_Delay_Days > 7 OR Defect_Rate_Percentage > 5 OR AI_Customer_Sentiment = negative Medium Risk Delivery_Delay_Days > 3 OR Defect_Rate_Percentage > 2 OR AI_Customer_Sentiment = mixed Low Risk All other cases The High Risk condition is evaluated first, so if a record satisfies both High and Medium conditions, it is classified as High Risk. This creates an important separation: AI → Provides enrichment and narrative insight Business Rules → Determine the authoritative Overall Risk For governance-sensitive supplier decisions, this separation can make the solution easier to validate and explain. 11. Creating the Final Business Dataset After all transformations are complete, the notebook creates a business-facing dataset containing several categories of information. Order Order_ID Order_Date Supplier Supplier_ID Supplier_Name Supplier_Rating Material Material_ID Material_Name Category Plant Quantity Ordered_Qty Delivered_Qty Quantity_Variance Quantity_Fulfillment_Percentage Delivery Promised_Date Actual_Delivery_Date Delivery_Delay_Days Delivery_Status Delivery_Performance Quality Quality_Score Defect_Qty Defect_Rate_Percentage AI Enrichment AI_Issue_Category AI_Customer_Sentiment AI_Extracted_Information AI_English_Remark AI_Supplier_Risk_Analysis Final Risk Overall_Risk The final structure combines source data, calculated KPIs, AI-generated enrichment, and deterministic risk classification in one dataset. 12. Persisting the Results in Delta The final dataset is written to a Fabric Delta table: supply_chain_ai_analysis The notebook uses overwrite mode with schema overwrite enabled. This means the current implementation replaces the target table rather than performing incremental updates. For a production workload that is refreshed regularly, an incremental or upsert strategy would likely be more appropriate. 13. Creating a Management Summary The notebook also creates a management-level risk summary. The data is grouped by: Overall_Risk and calculates: Order count Average delivery delay Average defect rate The output is ordered as: High Risk Medium Risk Low Risk This gives management a quick view of the overall supplier-risk distribution without having to inspect individual orders. Why Combine AI with Traditional Analytics? The key idea behind this solution is not to replace traditional analytics with AI. Instead, the two complement each other. Traditional Analytics AI Enrichment Delivery delay Issue classification Quantity variance Sentiment analysis Fulfillment % Information extraction Defect rate Translation Quality score Risk narrative Deterministic risk Unstructured text understanding This creates a more complete supplier-performance view. For example: Delivery Delay: 8 days Defect Rate: 1.5% Customer Sentiment: Negative AI Issue: Late Delivery AI Extracted Information: Shipment delay AI Risk Analysis: Supplier requires attention... Overall Risk: High The numbers provide the measurable evidence, while AI helps interpret the unstructured information. Important Lessons from the Implementation There are several important considerations when moving this type of solution from a demonstration to production. 1. Remove the Demo Record Limit The notebook currently uses: df = df.limit(25) This is intended for demonstration/testing and should not be treated as production logic. 2. Use a Controlled Schema The current implementation uses: inferSchema=True This is convenient during development, but production pipelines should generally use a controlled schema to avoid unexpected type inference. 3. Validate AI Outputs AI-generated classification, sentiment, extraction, translation, and narrative responses can vary. Therefore, AI outputs should be validated against business expectations before being used for important business decisions. 4. Keep Business-Critical Risk Rules Deterministic The implementation deliberately keeps Overall_Risk separate from the generated AI narrative. This means the AI can provide additional context without becoming the authoritative source for the final risk classification. 5. Add Monitoring Before Production A production implementation should consider monitoring: AI function failures Processing duration Record counts Output completeness Data-quality issues AI output quality The technical documentation also recommends adding appropriate validation and monitoring around the AI processing. What's Next? This notebook provides the data-processing and AI-enrichment layer. A natural next step would be to connect the resulting Delta table to a downstream reporting layer and build a management dashboard around: Supplier risk distribution Delivery performance Defect rate Quantity fulfillment AI issue categories Customer sentiment Supplier-specific AI risk analysis The uploaded implementation currently creates the Delta table and displays the results; a downstream Power BI semantic model/report is not included in the notebook. Final Takeaway This solution demonstrates how Microsoft Fabric can bring traditional data engineering and AI capabilities together in a single workflow. The pipeline starts with operational supply-chain data and progressively enriches it: Raw Supplier Data ↓ Data Preparation ↓ Operational KPIs ↓ AI Classification ↓ Sentiment Analysis ↓ Information Extraction ↓ Translation ↓ AI Risk Narrative ↓ Deterministic Overall Risk ↓ Delta Table The most important takeaway is that AI does not have to replace traditional business logic. Instead, Fabric AI Functions can be used where they provide the most value—understanding unstructured information—while deterministic PySpark rules continue to handle measurable and governance-sensitive business decisions. This combination provides a practical pattern for building AI-enriched analytics solutions in Microsoft Fabric.34Views0likes0CommentsBuilding an AI-powered quote engine on Microsoft Fabric
The problem Sales teams for technical products often get free-text enquiries like: "I need 4 x 5T chain hoists, 10m lift, for offshore use" Turning that into a quote usually means someone manually matching the product, checking the bill of materials, checking stock, checking supplier lead times, and pricing it up. I wanted to see how far Fabric's native AI capability could get toward automating that whole chain, without reaching for an external LLM service. What I built A proof of concept entirely inside one Fabric workspace: A Lakehouse holding a synthetic but realistic-looking dataset: a product catalogue (chain hoists, wire rope hoists, lever hoists, beam clamps, trolleys), a bill-of-materials per product, inventory levels, supplier lead times, and pricing A set of notebooks using Fabric's built-in AI Functions to read a customer enquiry and turn it into a structured, priced draft quote — matching the enquiry to a product, exploding the BOM by order quantity, checking stock, and rolling up a price and lead time A simple interactive demo — type an enquiry into a text box, click a button, get a quote back — running entirely inside a notebook, no external app or Azure OpenAI resource needed I deliberately made some components tight on stock (gearboxes, motors, brakes — the genuinely long-lead-time parts), so the demo shows a real "can we fulfil this now, or is it pending procurement?" decision, not just a happy path. The interesting part Real enquiries aren't always single, clean requests — customers often ask for a few different things in one message ("2 hoists, one standard and one offshore"). The AI extraction naturally returns one value per field, so it initially collapsed multi-item enquiries into a single line and silently dropped part of the request. Getting a reliable split-then-process approach working — without it silently swallowing half the enquiry — was the trickiest part to get right. A couple of smaller but important lessons: null/missing values from the AI extraction need explicit handling in code rather than relying on prompt instructions alone, and discontinued or not-yet-launched products need to be filtered out at the matching stage so the system doesn't quietly quote something no longer sold. Happy to go into more detail on the data model or the AI extraction approach if anyone's tackling something similar on Fabric.67Views1like0CommentsSMDoc: Semantic Model Documentation Workload
Workload Idea is to turn Power BI semantic model into a complete, editable documentation package (diagram + PDF + artifacts) inside Fabric, only in 7–10 clicks, in PDF format. Just click-click-click and have a semantic model documentation in PDF format. Problem Solved Pain point: Documentation for semantic models is time-consuming, fragmented, and often out-of-date. I am sure people have created notebooks using INFO functions, but I was not able to find a document solution for diagram layout. Analytic Endeavors has a solution in their future release but that's for the desktop. I embeded draw.io into my workload for a diagram editor. It is a free tool and works great with the code, unlike visio. Solution: Automates metadata extraction, produces a high-fidelity draw.io diagram, generates a PDF summary, and stores artifacts in OneLake — all from within Fabric so teams can document, review, and share models quickly and reproducibly. How It Works Create: Add a new SMDoc item in Fabric and open the Setup tab. Configure: Choose workspace, lakehouse, and semantic model, all from drop-downs. No manual inputs IDs or names. Generate: Click “Generate Doc File” — SMDoc programmatically creates and runs a Fabric Notebook to extract metadata and build artifacts, mainly through semantic link labs so no token generation require at each run like in Fabric Rest API. Edit: Open the embedded draw.io editor to inspect or modify the ER diagram. Main feature of my workload. Export/Combine: Export SVG/PDF and optionally merge diagram + summary into a single deliverable. Key Features Embedded Draw.io: Interactive, colorful ER diagrams editable directly inside Fabric. Notebook Orchestration: Automated notebook creation and execution via Fabric Platform APIs. High-Resolution Output: 4K vector-quality PDFs and SVG exports for print-quality documentation. Lakehouse Artifacts: Saves CSV artifacts and Delta tables to OneLake for auditing and reuse. Quick Workflow: End-to-end documentation in ~7–10 user actions, lowering time-to-insight. Limitations: Goal is to submit a working solution before the contest ends. Which is there and my workload is doing the job. Just some small tweaks required. PDF index layout: Index page sizing needs refinement. Post-merge metadata: Semantic vertipaq size and number of items not included after PDF combining in last step. UI tweaks: Lakehouse explorer is not yet resizable; initial item selection UX can be improved. Minor data gaps: Measures missing names in Delta exports (documented in repo). Logo: I missed the logo while making video. Added it now. Why It Matters Time savings: It takes 3 minutes to install libraries in notebook. Except that it takes less than a minute to get semantic modle PDF. Zero time and effort required from the user. Governance-ready: Produces auditable artifacts (CSV + Delta) for compliance and reviews. Extensible pattern: The notebook + embedded-editor approach is reusable for lineage, model comparison, or automated audits. Demo & Repo Demo video: (Watch the video to see the working in detail. If you have less time, just watch last 5 minutes of video) https://youtu.be/H0keB9JmlSg GitHub Repo: Removed the link. Found people copying the stuff without permission. To Discuss anything reach out on LinkedIn: https://www.linkedin.com/in/syed-haider-ali-shah I have used FUAM semantic model as an example. Was not able to find a complex free sample semantic model online.4KViews2likes0CommentsDataTrust BuiltIn Integrity for Lakehouse Pipelines Ingestion and Transformation
DataTrust Fabric DataTrust is a Fabric extension designed to ensure trusted end-to-end data movement across lakehouses by automatically validating ingestion and transformation pipelines. 1. The Challenge: The Integrity Blind Spot Current Microsoft Fabric workloads involve continuous data movement between lakehouses via complex pipelines. However, engineers currently face significant hurdles: Lack of Automation: Reliance on manual notebooks and ETL scripts without end-to-end integrity attestation. The Verification Gap: No native mechanism exists to verify if data was lost or unintentionally altered during execution. Trust Issues: Reduced confidence in downstream datasets and heavy manual validation overhead. Integrity vs. Quality: Unlike standard Data Quality checks (completeness, plausibility), this solution focuses on Data Integrity—ensuring the source and target lakehouses remain synchronized during execution. 2. The Solution: Automated Integrity Guardrails The Data Trust Extension introduces an automated validation workload directly within the Microsoft Fabric environment. Flexible Integration: Validation can be triggered as a native pipeline step, via a "Data Integrity" option in the Fabric UI, or by supplying a Spark job plan/notebook. Core Capabilities: Automated Comparison: Compares source and target lakehouse tables automatically. Record Match Metrics: Instant verification of row counts and synchronization. Field-Level Validation: Deep integrity checks at individual field level. Discrepancy Insights: Actionable insights instead of simple pass/fail results to accelerate root-cause analysis. 3. Impact and Outcomes By transitioning from assumed trust to proven trust, the extension delivers: Zero-Trust Movement: Continuous validation for every lakehouse-to-lakehouse transfer. Auditable Pipelines: Automated integrity scorecards for every execution. Efficiency: Faster troubleshooting and reduced manual validation overhead for data engineering teams. 4. Design 5. Demo Video The following videos demonstrate the UI integration, source/target table selection, and execution of an integrity validation job within Microsoft Fabric. The first part provides context. For a quick technical walkthrough, you may skip directly to the demo section. Watch the Context: Watch the Demo: 6. Fabric Portal Extension DataTrust Fabric transforms ingestion from a blind transfer into a verified, deterministic, and reliable process across lakehouses.5.2KViews0likes0CommentsFabric Monthly Sales Animation – Dynamic Dashboard Example
This project demonstrates an animated monthly sales dashboard built with Microsoft Fabric Notebooks. Key features: Line and Bar Charts: Animated trends and values Dynamic KPIs: Total, Average, Max, Min Dataset: Monthly sales CSV included Fully reproducible with the notebook Monthly_Sales_Animation.ipynb Watch the animation in action: YouTube Demo Repository link: GitHub – Fabric Monthly Sales Animation7.4KViews0likes0CommentsAgentic Excel to Fabric Migration Workload
🎯 A. The Problem Every mid and large organisation has hundreds - sometimes thousands or more - of Excel-based business processes driving critical reporting in areas such as finance. These teams know they *should* move to centralised platforms like Microsoft Fabric and Power BI, but face a brutal reality: 1) The skills gap is real: Generic Power BI training doesn't translate into building production-grade, enterprise-compliant analytics solutions. Users go on courses, try to apply the concepts to their own data, get stuck, and go back to Excel. Many organisations haven't even tried to upskill their analysts in Fabric yet, keeping data engineering activities with centralised Data/BI teams. 2) Technical debt creeps in fast. The reports that do get built are often rejected by Technical Review boards/COE teams for broader rollout because they fail to meet corporate Governance standards - data models are wrong, DAX is messy, governance and security requirements aren't met. That 100-page compliance document? Nobody knows how to translate it into Power BI or Fabric capabilities. 3) There's no bandwidth in centralised teams: Data engineering teams have massive backlogs, headcount is frozen, and business users can't wait months for a migration that the central team will never get to. Moreover, Gen AI alone doesn't solve it. It doesn't create data literacy, it exposes the challenges that come from a lack of it! Tools like Copilot give generic advice - they have no context about your specific business process, data structures, corporate requirements, or the nuances buried inside your spreadsheets. AI without context is just noise. The result? Critical financial processes stay trapped in ungoverned, unauditable spreadsheets, exactly where regulators don't want them! 💡 B. The Solution The Excel-to-Fabric Migration Agent is a multi-agent system built as a Fabric Workload that takes an Excel workbook as input and automates the entire journey into Microsoft Fabric, from understanding the business logic to deploying a fully governed, medallion-architecture data solution. In this scenario, Excel isn't just a data source, it's a specification document. Business users have already captured their data structures as tables and their business logic as formulas. The agent reads and understands this context, then uses it to design, build, and deploy the equivalent solution in Fabric, with the user validating at every step. 🔁 C. How it works: 1. Upload & Analyse: The user uploads an Excel workbook. The agent parses the XML structure, classifies sheets/data tables and cell blocks by role (Input, Lookup, Calculation, Output), and translates formulas into plain-English logic. It produces a human-readable Standard Operating Procedure (SOP) for the user to validate and highlight where 2. Architecture Design: The agent designs a three-tier medallion architecture (Bronze → Silver → Gold lakehouses) and writes Spark SQL Materialized Lake Views (as an example) that replicate the Excel calculation logic, handling format mismatches, implicit joins, and cross-sheet references automatically. 3. Fabric Deployment: Lakehouses are created, CSVs uploaded, delta tables loaded, notebooks deployed, and OneLake shortcuts configured, all via Fabric REST APIs. The user sees live deployment progress with status indicators. 4. Power BI Modeling: A star schema semantic model is created with DAX measures, and a comprehensive SOP documentation workbook is generated with Power Query connections to every lakehouse table, so outputs can still be reviewed in Excel via a live OneLake connection. Human-in-the-loop throughout.: The agent pauses at every phase boundary for user validation; it never deploys without explicit confirmation. 🏗️ D. Architecture & Tech Stack The solution consists of the following components: 1. AI Context Engineering: Context documents (markdown files) containing reuqirements, best practices and instructions for each agent. 2. Agent Framework: Multi-agent orchestration with 4 specialised worker agents 3. Workload Frontend: Built using the Fabric Extensibility Toolkit (React + Fluent UI) 4. Excel Parsing capabilities: Code to save the XLSX file as XML files for analysis 5. Fabric Lakehouses: Represented in a Medallion pattern (Bronze / Silver / Gold) 6. Fabric Notebooks: Business Logic included e.g. as Pyspark or Spark SQL Materialized Lake Views (MLVs) 7. Fabric Deployment: Via Fabric REST APIs, OneLake DFS API, Lakehouse Table Load API 8. Semantic Layer Build: Automatic Power BI semantic model build where required (TMDL format) with DAX measures 9. Documentation: Auto-generated SOP Excel workbook with Power Query M connections to OneLake Lakehouses. ✨ E. Key Features 1). 📊 Excel-native starting point: Meets users where they are. No need to describe requirements from scratch as the agent reads the workbook and extracts the existing process. 2) 🏛️ Enterprise-grade architecture: Automatically designs medallion lakehouses with proper cross-lakehouse references, format normalisation, and join resolution. 3) 🔁 Formula-to-SQL/Python translation: Converts Excel calculation logic (e.g. SUMIFS, VLOOKUPs, IF statements) into equivalent SQL/Python Code 4) 🚀 One-click deployment : Creates lakehouses, uploads data, deploys notebooks, and configures shortcuts through Fabric APIs; no manual setup required. 5) 📋 Auto-generated SOP: Produces complete Standard Operating Procedure documents with process steps, validation checks, and colour-coded sheet references. 6) 🔒 Human-in-the-loop: User checkpoints at every phase boundary ensures the agent never deploys without explicit validation. 7) 📈 Power BI ready: Outputs a star schema semantic model and an Excel workbook with live Power Query connections to the deployed lakehouse tables. The solution video is split into three parts: Part I - https://share.synthesia.io/ef56645f-54ed-4da5-9fa5-29446948abbc Part II - https://share.synthesia.io/509a6433-77ed-4e88-b49b-4cec3e705f39 Part III - https://share.synthesia.io/40b58940-2f5b-4b90-bdd3-ba8a9afea4b68KViews3likes0CommentsMetric Intelligence Layer for Microsoft Fabric- KHantix
Metric Intelligence Layer for Microsoft Fabric- KHantix 1. Problem Solved Pain Point Small and medium-sized businesses struggle not because they lack data — but because they lack clarity on what metrics to measure and how to calculate them correctly. Current BI workflows create several challenges: Metric definitions are inconsistent across teams Users must manually determine which KPIs are relevant DAX and calculation logic require technical expertise AI tools (e.g., Copilot) cannot reliably recommend metrics without structured metadata Dashboard creation is time-consuming and error-prone Even when semantic models exist, they do not guide users toward validated, business-aligned metrics. The result is duplicated effort, incorrect KPI logic, and low trust in analytics. 2. Solution Metric Intelligence Layer introduces a metrics-first automation approach inside Microsoft Fabric. The workload: Automatically scans uploaded datasets to detect business entities and structures Matches detected entities against curated, industry-standard metric libraries Validates data feasibility before recommending metrics Programmatically generates DAX measures Assembles structured, ready-to-use dashboard templates Stores metric metadata and artifacts in OneLake for governance and reuse All of this occurs within Fabric, enabling teams to move from raw data to trusted dashboards in a guided, reproducible workflow. 3. How It Works Create Add a new Metric Intelligence Layer item in Fabric and open the Setup tab. Configure Select: Workspace Lakehouse or Warehouse Target dataset or data source All selections are made through controlled drop-down menus — no manual ID inputs required. Scan Click “Analyze Dataset”. The workload programmatically creates and executes a Fabric Notebook that: Extracts schema and metadata Identifies business entities (customers, transactions, campaigns, revenue, etc.) Validates available fields and date granularity Prepares structured metadata artifacts The process leverages Fabric-native APIs and notebook orchestration — no repeated manual token handling required. Recommend Based on detected entities, the system: Matches the dataset against industry metric libraries (Sales, Marketing, SaaS, Finance, E-commerce) Recommends relevant KPIs Explains why each metric matters Flags feasibility constraints if required fields are missing Only validated metrics are suggested. Generate When the user confirms selected metrics: DAX formulas are automatically generated Measures are structured for semantic model integration A dashboard scaffold is assembled programmatically Structured metric metadata is stored in OneLake (Delta tables + JSON packages) Review & Refine Users can: Inspect generated metric definitions Modify descriptions or tags Adjust metric parameters Export metric metadata packages for AI/Copilot workflows 4. Key Features AI-Powered Metric Detection Automatically detects business entities and recommends KPIs aligned with industry best practices. Data Feasibility Validation Ensures required fields and granularity exist before proposing a metric. Automated DAX Generation Produces validated, standardized DAX measures ready for semantic model integration. Dashboard Scaffolding Creates aligned dashboard templates based on selected metrics. Governed Metric Library Stores metric definitions as certified Delta tables in OneLake with version tracking. AI-Ready Metadata Generates structured metadata packages optimized for Copilot and agent retrieval scenarios. Fabric-Native Orchestration Uses Fabric notebooks, OneLake storage, and semantic model integration through platform APIs. 5. Limitations The current prototype focuses on demonstrating the core value proposition and workflow: Automated push of measures directly into existing semantic models may require additional permissions or refinement Industry metric libraries are extensible but currently limited to predefined domains Advanced Copilot integration is demonstrated conceptually rather than fully automated UI refinement and configuration improvements are ongoing The workload is functional and demonstrates the end-to-end automation flow, with minor enhancements planned post-contest. 6. Why It Matters Time Savings Reduces dashboard creation time from weeks to hours by eliminating manual metric definition and validation. Increased Accuracy Standardized, validated metric logic improves consistency and trust across teams. Governance-Ready Metric definitions, validation artifacts, and metadata are stored in OneLake for auditability and reuse. AI Enablement Structured metric metadata enhances Copilot’s ability to recommend and explain KPIs correctly. Scalable Pattern The metrics-first architecture can be extended to: Industry-specific KPI packs Automated metric quality scoring Cross-model metric comparison Agent-driven analytics workflow Metric Intelligence Layer transforms Fabric from a powerful BI platform into a guided analytics engine — enabling organizations to build trusted dashboards without expanding technical headcount. Demo Video: https://share.synthesia.io/f746cf1f-fd37-4b92-9b08-a66c1733f345 Figma mockups: https://www.figma.com/make/FpbYvb5wEM5HmvoeaIN7y9/AI-Metrics-Dashboard-UI?p=f&t=tv7gplCe4mof9jlx-0&fullscreen=14.8KViews0likes0CommentsKHT Data Contract Toolkit - KHantix team
1. What It Does KHT Data Contract Toolkit is a Microsoft Fabric–native governance extension that operationalizes Data Contracts as executable controls inside the Fabric runtime. Instead of treating governance as documentation or monitoring, the toolkit enforces it directly within ingestion pipelines. It provides: Centralized Data Contracts as Code Schema, quality rules, ownership, certification level, and intended use are defined in version-controlled contracts stored in Git. Shift-Left Data Quality Enforcement Contracts are executed automatically during ingestion using Fabric notebooks and Spark-based validation. Deterministic Pipeline Control Validation outcomes control pipeline behavior: fail, warn, or quarantine. Lakehouse-Native Quarantine Invalid records are automatically isolated in structured Delta tables with full traceability. Governance Hub UI A centralized dashboard for viewing datasets, contract versions, validation history, ownership, and audit evidence. The solution is built entirely on Fabric primitives: OneLake, Delta Lake, Spark notebooks, Data Pipelines, and the Fabric Workload SDK — with no external SaaS dependencies. 2. What Problem It Solves Microsoft Fabric provides strong governance building blocks such as: Delta Lake schema enforcement RLS / CLS Sensitivity labels Microsoft Purview However, these capabilities are fragmented and lack a central Data Contract layer to coordinate quality, ownership, security context, and auditability end to end. As a result, small teams in regulated environments face: Manual Audit Overhead Governance evidence is scattered across workspaces, pipelines, notebooks, and Purview. Audit preparation often takes 2–3 hours per request. Fragmented Validation Logic Quality rules are embedded in ETL code and SQL views, making them difficult to audit, reuse, or standardize. Late Error Detection Data quality issues are discovered after pipelines complete, wasting compute and impacting downstream systems. Unclear Accountability Ownership and responsibility are ambiguous during incidents or compliance reviews. The toolkit transforms governance from reactive monitoring to proactive, execution-layer enforcement. 3. Who It’s For The workload is designed for small data teams (under 10 people) operating in regulated industries where governance is mandatory. Primary personas: Data Platform Leads Need centralized, audit-ready visibility and enforceable governance without scaling headcount. Data Engineers Require reusable, shift-left validation guardrails that prevent non-compliant data from entering production. Data Stewards / Compliance Teams Need traceable, system-generated evidence for regulatory reporting and governance assurance. Target industries include: Financial Services, Banking, Securities, Healthcare, and Government. External resources: - Demo Video: KHT_Data Contract_Video - Document: The attached file.9.4KViews0likes0CommentsAuto Dashboard with MS Fabric Metric Intelligence Layer- KHantix
Metric Intelligence Layer for Microsoft Fabric- KHantix Problem Solved Pain Point Small and medium-sized businesses struggle not because they lack data — but because they lack clarity on what metrics to measure and how to calculate them correctly. Current BI workflows create several challenges: Metric definitions are inconsistent across teams Users must manually determine which KPIs are relevant DAX and calculation logic require technical expertise AI tools (e.g., Copilot) cannot reliably recommend metrics without structured metadata Dashboard creation is time-consuming and error-prone Even when semantic models exist, they do not guide users toward validated, business-aligned metrics. The result is duplicated effort, incorrect KPI logic, and low trust in analytics. Solution Metric Intelligence Layer introduces a metrics-first automation approach inside Microsoft Fabric. The workload: Automatically scans uploaded datasets to detect business entities and structures Matches detected entities against curated, industry-standard metric libraries Validates data feasibility before recommending metrics Programmatically generates DAX measures Assembles structured, ready-to-use dashboard templates Stores metric metadata and artifacts in OneLake for governance and reuse All of this occurs within Fabric, enabling teams to move from raw data to trusted dashboards in a guided, reproducible workflow. How It Works Create Add a new Metric Intelligence Layer item in Fabric and open the Setup tab. Configure Select: Workspace Lakehouse or Warehouse Target dataset or data source All selections are made through controlled drop-down menus — no manual ID inputs required. Scan Click “Analyze Dataset”. The workload programmatically creates and executes a Fabric Notebook that: Extracts schema and metadata Identifies business entities (customers, transactions, campaigns, revenue, etc.) Validates available fields and date granularity Prepares structured metadata artifacts The process leverages Fabric-native APIs and notebook orchestration — no repeated manual token handling required. Recommend Based on detected entities, the system: Matches the dataset against industry metric libraries (Sales, Marketing, SaaS, Finance, E-commerce) Recommends relevant KPIs Explains why each metric matters Flags feasibility constraints if required fields are missing Only validated metrics are suggested. Generate When the user confirms selected metrics: DAX formulas are automatically generated Measures are structured for semantic model integration A dashboard scaffold is assembled programmatically Structured metric metadata is stored in OneLake (Delta tables + JSON packages) Review & Refine Users can: Inspect generated metric definitions Modify descriptions or tags Adjust metric parameters Export metric metadata packages for AI/Copilot workflows Key Features AI-Powered Metric Detection Automatically detects business entities and recommends KPIs aligned with industry best practices. Data Feasibility Validation Ensures required fields and granularity exist before proposing a metric. Automated DAX Generation Produces validated, standardized DAX measures ready for semantic model integration. Dashboard Scaffolding Creates aligned dashboard templates based on selected metrics. Governed Metric Library Stores metric definitions as certified Delta tables in OneLake with version tracking. AI-Ready Metadata Generates structured metadata packages optimized for Copilot and agent retrieval scenarios. Fabric-Native Orchestration Uses Fabric notebooks, OneLake storage, and semantic model integration through platform APIs. Limitations The current prototype focuses on demonstrating the core value proposition and workflow: Automated push of measures directly into existing semantic models may require additional permissions or refinement Industry metric libraries are extensible but currently limited to predefined domains Advanced Copilot integration is demonstrated conceptually rather than fully automated UI refinement and configuration improvements are ongoing The workload is functional and demonstrates the end-to-end automation flow, with minor enhancements planned post-contest. Why It Matters Time Savings Reduces dashboard creation time from weeks to hours by eliminating manual metric definition and validation. Increased Accuracy Standardized, validated metric logic improves consistency and trust across teams. Governance-Ready Metric definitions, validation artifacts, and metadata are stored in OneLake for auditability and reuse. AI Enablement Structured metric metadata enhances Copilot’s ability to recommend and explain KPIs correctly. Scalable Pattern The metrics-first architecture can be extended to: Industry-specific KPI packs Automated metric quality scoring Cross-model metric comparison Agent-driven analytics workflow Metric Intelligence Layer transforms Fabric from a powerful BI platform into a guided analytics engine — enabling organizations to build trusted dashboards without expanding technical headcount. Demo Video: https://share.synthesia.io/f746cf1f-fd37-4b92-9b08-a66c1733f345 Figma mockups: https://www.figma.com/make/FpbYvb5wEM5HmvoeaIN7y9/AI-Metrics-Dashboard-UI?p=f&t=tv7gplCe4mof9jlx-0&…7.9KViews0likes0CommentsFabric Lists
Hello Fabric Community! I'm excited to submit Fabric Lists for the Fabric Extensibility Toolkit Contest! What is Fabric Lists? Fabric Lists is a workload for Microsoft Fabric that empowers business users to create and manage their own data tables with a simple, intuitive interface - directly within Fabric. What problem does it solve? Say goodbye to: Manual tables and Excel imports Unmanaged Power Apps Hidden SharePoint lists Unreliable imports that break due to user changes (renaming columns, wrong date formats, missing data) Entering data manually in SQL Management Studio or even worse: in the Power Query editor Endless CASE WHEN statements hardcoded in your queries Mystery edits with no audit trail - Fabric Lists has built-in tracking of who created and modified each row Now business users can manage their budget and mapping tables themselves, without creating headaches for the data or IT department. Who is it for? Business users who need to maintain reference data, mapping tables, or simple datasets - with IT maintaining governance and control through Lakehouse integration. Key Features No backend required - Data stored as CSV directly in Lakehouse Files section Type-safe columns - Prevent data entry errors with datatype validation Built-in auditing - Automatic tracking of creation and update timestamps Inline editing - Fast, Excel-like editing experience Search functionality - Quickly find the data you need Automation triggers - Execute notebooks or pipelines on save or via custom buttons Shortcut Transformation ready - Automatically transform CSV to managed tables for SQL endpoint access Screenshots Lakehouse connection Basic list Inline editing Data types Bulk edit Action buttons Action buttons Action on save; execute notebook or pipeline Demo Video GitHub Repository https://github.com/daxternl/fabric-extensibility-toolkit Future Roadmap: Advanced filtering capabilities Advanced validation (regex support) Multi-value fields for one-to-many relations Dropdown fields based on other lists Bulk edit calculations to easily manage budgets Change Data Capture with history rollback SQL backend option for enhanced performance Why Fabric Lists? This workload bridges the gap between business user needs and IT governance. Data stays in your Lakehouse, users get a simple interface, and IT maintains full control - all without requiring external tools or backends. I'd love to hear your feedback and answer any questions!941Views1like0Comments