Lost Track of Which Feature Workspace Belongs to What? Fabric's New Relations API Fixes That
The problem: branch workspaces multiply, and nothing tracks them If your team uses Fabric's Git integration with branching, you've probably experienced this pattern: someone creates a new feature branch in source control, and Fabric spins up a matching "feature workspace" so they can build and test in isolation without touching the shared Dev or Test environment. This is genuinely useful - it means multiple people can work on different features at the same time without stepping on each other's changes. The trouble shows up a few weeks later. You've now got a dozen feature workspaces sitting in your tenant, and there's no built-in way to look at one and know which project it belongs to, who created it, or whether it's safe to delete. Some of those branches got merged and closed out weeks ago, but the workspace never got cleaned up. Others are still actively being used. From the outside, they all just look like... workspaces. Sorting that out has generally meant manually checking naming conventions, asking around, or just leaving stale workspaces sitting there because nobody wants to risk deleting the wrong one. What Fabric's Workspace Relations API actually does In the August 2026 Fabric update, Microsoft introduced a set of API endpoints that let you create, query, update, and delete relationships between workspaces - specifically, the link between a "parent" workspace (your main Dev or Test environment) and the "branch" or "feature" workspaces created from it. In plain terms: instead of a feature workspace being just another disconnected item in your tenant, it now carries an explicit, query able record saying "I belong to this parent workspace." Any tool, script, or automation you build can ask Fabric directly, "show me every branch workspace linked to this parent," and get a real answer - not a guess based on naming patterns. A real example Picture a typical setup: your team's Git-integrated Fabric project has one main Dev workspace, and every time someone starts a new feature branch, an automated pipeline (using Azure DevOps or GitHub Actions) spins up a matching feature workspace, configures its Git connection, and sets the right permissions.Here's where the Relations API closes the loop: after that feature workspace is provisioned, the pipeline calls the Relations API to explicitly link it back to the parent Dev workspace. From that point forward: Anyone (or any script) can query "which branch workspaces belong to this parent?" and get a complete, accurate list When a feature branch gets merged and its workspace is no longer needed, a cleanup script can safely identify orphaned branch workspaces tied to a specific parent, instead of relying on someone remembering to delete it manually If your organization runs a periodic governance check ("do we have workspaces nobody's touched in 60 days?"), that check can now also confirm which parent each one belongs to, making it much easier to decide what's safe to remove None of this requires manually maintaining a spreadsheet or a naming convention discipline that inevitably breaks down over time. The relationship is a real, first-class piece of information Fabric tracks for you. Where this saves the most time Teams using Git branching heavily, where feature workspaces are created and torn down frequently as part of normal development Governance and cleanup routines, where knowing "does this workspace still have a live purpose" used to require manual investigation Building your own internal tooling or dashboards that need to show a clear picture of your Fabric tenant's workspace structure, rather than a flat, unorganized list What to keep in mind This is an API-level capability, so using it directly means writing a bit of automation - typically something your DevOps or platform team would set up as part of your existing branch-workspace pipeline, rather than something you'd click through in the Fabric UI Day to day. If that's not your role, the practical takeaway is simpler: ask whoever manages your team's Git integration and CI/CD setup whether this is wired into your branch workspace pipeline yet. It turns "we have no idea which workspaces are still needed" into a question your tooling can actually answer. If your tenant has been quietly accumulating feature workspaces with no clear ownership trail, this is worth bringing up with your Fabric admin or platform team as a governance improvement. Thanks for reading! Connect with me on: LinkedIn | Data With Pankaj - YouTube
Fantasy Premiere League Analytics Hub v3
Multi Seasonal Report to help Fantasy managers track player performance discover hidden gems and undervalued assets Main changes from previous version: Changed the pipeline from just python > powerbi to python >sql databae > powerbi' This was done to handle multi season analysi as the previous pipeline wasnt fit to do so Utilised bronze silver gold staging in sql More contextualised kpis Customiseable charts (parameters) Utilised HTML visuals for KPIs, Visuals (player explorrer page) and tooltips Star Schema Data Model eyJrIjoiMTVjMTdkMWEtZTQwOS00NDM0LTkxYTEtMjJmODY2ZDhmMTY0IiwidCI6ImQxMjA2OTQzLWJmY2MtNGM3NC04MmQ0LTA1ZTYzYTQzMzViZiJ9Model Explainability That Goes Beyond the Notebook for Data Science in Microsoft Fabric
A machine learning model can be remarkably accurate and still leave people completely unconvinced. That is one of the strange realities of working in data science. You can spend weeks cleaning data, testing algorithms, tuning parameters, and validating performance, only to reach the moment when somebody looks at a prediction and asks a very reasonable question: “Why?” Suddenly, accuracy alone does not feel like enough. A probability score might tell you what the model believes, but it does not necessarily help the person receiving that prediction understand how the model arrived there. That gap between prediction and understanding is exactly where model explainability becomes important. What you will learn: In this edition, we’re exploring model explainability in production and how SHAP, FastAPI, and Plotly can work together to make predictions easier to understand. By the time you’re done with this, you’ll have a clear view of how SHAP can explain individual model decisions, how those explanations can be served dynamically through an API, and how interactive visualizations can turn technical attribution values into something far more approachable. Source: Sahir Maharaj (https://sahirmaharaj.com) It is tempting to think of explainability as a chart you generate after training a model, but production explainability is really an ongoing capability. Every new observation can produce a different prediction, and every prediction may have a different explanation. A customer predicted to leave a service might receive a high risk score because of declining engagement, while another customer receives the same score because of repeated service issues. The prediction may look identical at the surface, but the reasoning behind it can be completely different. That difference matters when somebody needs to decide what to do next. This is where SHAP becomes particularly valuable because it gives you a structured way to describe feature contributions. Imagine a model predicting whether a machine is likely to fail. The prediction itself might tell you that failure risk is 82 percent. Useful, certainly, but incomplete. SHAP can help reveal that rising operating temperature, vibration intensity, and unusually long operating hours are pushing the prediction upward, while another factor such as recent maintenance is reducing the predicted risk. Suddenly the prediction becomes much easier to reason about. You still have a probabilistic model, but you also have something resembling an explanation of its behavior. As a data scientist, I find that this distinction between global and local understanding is especially important. During model development, I often want to understand the model globally. Which variables matter most overall? Is the model relying heavily on variables I expected it to use? Are there surprising relationships hiding in the data? In production, however, people often care about something much more specific. They want to know why this customer, this transaction, this machine, or this observation received the prediction it did. That is a local explanation, and SHAP is particularly useful for helping bridge that gap. Source: Sahir Maharaj (https://sahirmaharaj.com) You can think about the difference through a credit-risk example. Globally, a model might rely heavily on payment history, debt ratios, and income stability. That tells you something useful about the overall model. But suppose one applicant receives a higher risk prediction than expected. A general feature importance chart does not really answer the person's question. You need to understand what happened for that particular prediction. Perhaps the debt ratio increased the risk score significantly, while long-term employment reduced it. That level of explanation provides much more context than simply showing which variables matter across thousands of predictions. Explainability can also become an important debugging tool for you as the person building the model. Suppose a model performs well according to the metrics you are monitoring, but its explanations repeatedly show that one unexpected variable dominates many predictions. That should make you curious. import numpy as np import pandas as pd import shap import matplotlib.pyplot as plt from sklearn.ensemble import RandomForestClassifier from sklearn.model_selection import train_test_split np.random.seed(42) n = 800 X = pd.DataFrame({ "usage_drop": np.random.normal(20, 10, n), "support_calls": np.random.poisson(3, n), "login_days": np.random.randint(1, 30, n), "tenure_months": np.random.randint(1, 72, n), "monthly_cost": np.random.normal(80, 20, n) }) score = ( 0.08 * X["usage_drop"] + 0.45 * X["support_calls"] - 0.05 * X["login_days"] - 0.02 * X["tenure_months"] + 0.015 * X["monthly_cost"] ) y = (score + np.random.normal(0, 1, n) > np.median(score)).astype(int) X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.25, random_state=42 ) model = RandomForestClassifier(n_estimators=150, random_state=42) model.fit(X_train, y_train) explainer = shap.TreeExplainer(model) values = explainer(X_test) class_values = values[:, :, 1] if values.values.ndim == 3 else values shap.plots.beeswarm(class_values, max_display=5) plt.show() shap.plots.waterfall(class_values[0], max_display=5) plt.show() Imagine that somebody submits new information to a prediction service. The model receives those features, processes them, and generates a result. If explainability is part of the design, the same interaction can also produce SHAP information describing the important factors behind that specific prediction. Instead of storing explanations for every imaginable case beforehand, you generate them when they are needed. FastAPI fits naturally into this kind of workflow because it gives the prediction and explanation process a consistent interface. Rather than another application needing to understand your model directly, it can send the required information to an API. The API can coordinate the prediction process, calculate the explanation, and return the relevant output. The application consuming the result does not need to know the mathematical details of SHAP or how the model itself works internally. It simply receives information in an agreed structure. That separation can make a production system much easier to manage. From what I observe when building data science workflows, this separation becomes valuable surprisingly quickly. During early experimentation, everything often exists together. Data preparation, prediction, explanation, and visualization may all happen inside one environment. That is perfectly reasonable when you are exploring an idea. Production introduces more responsibilities. The application requesting a prediction should not need access to the entire modeling environment, and your model should not depend on somebody manually generating explanations. Creating a clear service boundary helps each part of the system do its job without becoming unnecessarily tangled with everything else. Dynamic explanations also give you flexibility over how much information you return. A technical monitoring application may want detailed SHAP values for every available feature. A decision-support interface may only need the five strongest contributors. Another application may need a short summary explaining the strongest positive and negative influences. The explanation engine can be the same while the presentation changes according to the audience. That matters because explainability is not only a modeling problem. It is also a communication problem. Source: Sahir Maharaj (https://sahirmaharaj.com) Performance deserves careful attention here as well. Calculating an explanation adds work beyond producing the prediction itself, and depending on the model, the amount of additional work may not be trivial. That does not mean explanations should be avoided. It means you should think about when they are required. Some systems may need an explanation for every single prediction. Others may generate explanations only when a user requests additional detail. You might also decide that certain high-impact decisions always receive explanations while low-impact automated predictions do not. Production design is often about finding that balance between completeness and responsiveness. There is also an important consistency issue. An explanation is only useful if it corresponds to the exact model and transformation process that generated the prediction. Imagine updating your model but accidentally continuing to generate explanations using an older version. The results could look perfectly reasonable while describing behavior that no longer matches the prediction being shown. import numpy as np import pandas as pd import shap import plotly.graph_objects as go from sklearn.ensemble import GradientBoostingClassifier np.random.seed(7) n = 700 X = pd.DataFrame({ "temperature": np.random.normal(70, 12, n), "vibration": np.random.normal(4, 1.5, n), "operating_hours": np.random.normal(900, 250, n), "maintenance_days": np.random.randint(1, 120, n) }) risk = ( 0.06 * X["temperature"] + 0.7 * X["vibration"] + 0.003 * X["operating_hours"] - 0.025 * X["maintenance_days"] ) y = (risk + np.random.normal(0, 1, n) > np.median(risk)).astype(int) model = GradientBoostingClassifier(random_state=7) model.fit(X, y) explainer = shap.Explainer(model, X) row = pd.DataFrame([{ "temperature": 92, "vibration": 6.8, "operating_hours": 1250, "maintenance_days": 75 }]) prediction = model.predict_proba(row)[0, 1] explanation = explainer(row) names = row.columns.tolist() impacts = explanation.values[0] waterfall = go.Figure(go.Waterfall( orientation="h", y=names, x=impacts, measure=["relative"] * len(names), text=[f"{x:+.2f}" for x in impacts], textposition="outside" )) waterfall.update_layout( title="SHAP Explanation: What Drove This Prediction?", xaxis_title="SHAP Impact on Model Output", yaxis_title="Feature", height=450 ) waterfall.show() gauge = go.Figure(go.Indicator( mode="gauge+number+delta", value=prediction * 100, number={"suffix": "%"}, delta={"reference": 50}, title={"text": "Predicted Machine Failure Risk"}, gauge={ "axis": {"range": [0, 100]}, "steps": [ {"range": [0, 40]}, {"range": [40, 70]}, {"range": [70, 100]} ], "threshold": { "line": {"width": 4}, "thickness": 0.8, "value": prediction * 100 } } )) gauge.update_layout(height=400) gauge.show() pd.DataFrame({ "Feature": names, "Value": row.iloc[0].values, "SHAP Impact": impacts }).sort_values("SHAP Impact", key=abs, ascending=False) The third objective is turning those explanation values into something people can interpret without needing to understand every detail of SHAP. This is where visualization becomes more than decoration. Raw values can tell you exactly how features influenced a prediction, but they require effort to interpret. A Plotly visualization can organise those contributions so the strongest influences immediately stand out. Features pushing a prediction in one direction can be separated visually from those pushing it in the opposite direction, allowing somebody to understand the basic story of the prediction within a few moments. Imagine a customer churn model that predicts an unusually high probability of cancellation. A dynamic explanation might show that a recent drop in product usage is the strongest contributor, followed by repeated support contacts and a reduction in login frequency. At the same time, a long customer relationship might slightly reduce the churn prediction. That is much more meaningful than presenting a table containing feature names and decimal values. The visualization helps the reader understand not only which features mattered but also how they worked together. Source: Sahir Maharaj (https://sahirmaharaj.com) When I look at explanations intended for other people, I try not to assume that more information automatically creates more transparency. It is very easy to generate a detailed visualization containing dozens of variables simply because the values are available. The result may technically be comprehensive while being practically overwhelming. If somebody has to study a chart for several minutes before understanding the main message, the explanation probably needs refinement. In many situations, highlighting the strongest contributors and allowing additional detail to be explored when needed creates a much better experience. Interactivity can make this even more useful. Plotly allows explanations to become something people can investigate instead of merely observe. A user might hover over a feature to inspect the contribution more closely or compare several predictions to understand why similar observations received different results. Imagine comparing two loan applications that received different risk scores. An interactive explanation can make it easier to see that one prediction was strongly influenced by debt levels while another was affected primarily by inconsistent payment history. That comparison helps reveal how the model responds to different combinations of information. At the same time, visual polish should never become a substitute for clarity. A sophisticated interactive chart can create an impression of authority, and that means you have a responsibility to provide enough context around what the visualization represents. The user should understand that the chart explains the model's behavior, not necessarily the underlying truth of the real-world situation. If a feature makes a large contribution, that means the model relied heavily on that feature for the prediction. It does not automatically prove that the feature caused the outcome. Keeping that distinction clear is a major part of responsible model communication. Source: Sahir Maharaj (https://sahirmaharaj.com) So give it a try. Do not wait until you have a huge production system or a complicated machine learning platform before thinking about transparency. Start with one prediction, one explanation, and one clear visualization. Build from there as your understanding grows. The more comfortable you become explaining what your model is doing, the easier it becomes to recognise when its behaviour deserves a closer look. And that ability is valuable whether you are just entering data science or have been building models for years. If you ever need anything while exploring it, just reach out to me. I’ll be more than happy to help. Thanks for taking the time to read my post! I’d love to hear what you think and connect with you! 🙂 LinkedIn Kaggle Topmate (Free Power BI / Data Science Sessions and Resources) Website The Tech Journal (Blog) About the author Sahir Maharaj is a Lead Data Scientist who leads the design and deployment of end-to-end AI solutions that drive strategic decisions at scale. As a Microsoft MVP, he has been featured internationally, including in The Indian Express and on New York's Times Square billboards, and is a prolific content creator on LinkedIn.From Chaos to Clarity: A Supply Chain Response App with Fabric's SQL Database
Supply chains break in ways that rarely announce themselves in advance. A supplier goes dark, a shipment stalls at a border, a single component runs low in a warehouse halfway across the world — and suddenly a business is scrambling to figure out what's actually happening and what to do about it. The businesses that recover fastest aren't the ones with the fewest disruptions; they're the ones who can see the problem the moment it appears. That's the premise behind a hands-on project I've been working through: building a Supply Chain Disruption Response App entirely inside Microsoft Fabric, using its native SQL database capability. No separate database server to provision, no disconnected BI layer bolted on afterward — just one unified platform taking raw supplier and warehouse data and turning it into something a team can actually act on. It's a big enough build that I'm splitting it into a short series. This first post covers the full data foundation — standing up the workspace and database, loading and shaping the data, layering analytical views on the SQL analytics endpoint, and turning it all into a live Power BI report. Later posts will pick up from here and cover notebooks, DevOps, a GraphQL API, and finally a real web application. Here's how the foundation came together, and what stood out along the way. Starting with a Workspace, Not a Server The first thing that struck me about Fabric is how little "infrastructure thinking" it requires. There's no spinning up a VM, no configuring a database engine from scratch. Everything begins with a workspace — essentially a shared home for every item in the project: databases, pipelines, notebooks, and reports all live side by side. Setting one up is a matter of naming it, attaching it to a Fabric capacity, and deciding on a semantic model storage format. Ten minutes in, I had a dedicated space — Supply Chain Analytics Workspace — ready to hold the entire project without a single line of provisioning script. Spinning Up the Database From there, creating the actual SQL database is almost anticlimactic in its simplicity: a name, a click, and Fabric provisions a fully managed SQL database behind the scenes. I called mine supply_chain_analytics_database, and within moments it was ready to accept data. Fabric even ships with sample retail data (the familiar SalesLT schema — customers, products, orders) that loads in with one click. It's a small touch, but it meant I could start writing real queries immediately instead of wrestling with seed data. Teaching the Database to Think About Supply Chains Sample sales data is useful, but it doesn't know anything about supply chains. So the next step was to give the database a vocabulary for the problem at hand: a dedicated SupplyChain schema, and inside it, a Warehouse table modeling the essentials — which product ties to which component, which supplier provides it, where that supplier is located, and how much stock is currently on hand. Rather than hand-typing rows, I populated the table directly from the existing product catalog, using T-SQL to generate plausible component, supplier, and location IDs on the fly. In a few lines of script, the database went from "generic retail demo" to "a working model of a multi-tier supply network" — the exact structure you'd need to trace a disruption back to its source. One small but genuinely useful discovery here: Fabric's query editor has a Copilot-style assist built in. Typing a plain-English comment like "show the total number of customers" and pressing Tab generates the T-SQL for you — and there's an "Explain query" option that annotates existing code step by step. For anyone who's ever inherited a gnarly SQL script with zero comments, this alone is worth the price of admission. Bringing in the Outside World Real supply chains don't live in one database — they're distributed across vendors, partners, and legacy systems that were never designed to talk to each other. To simulate that, I used a Fabric Data Pipeline with a Dataflow Gen2 to pull supplier data from an external OData feed (in this case, the Northwind Traders sample service), representing a partner organization sharing the same supplier network. https://services.odata.org/v4/northwind/northwind.svc/ What made this step interesting wasn't the mechanics — point, click, choose a table, run — but what it represents: Fabric's pipelines are built to treat "connect to an external partner's data" as a first-class, repeatable operation rather than a one-off script someone writes and forgets. Once the dataflow published and the database refreshed, a new Suppliers table appeared right alongside the internally generated data, ready to be joined. Turning Rows into Answers With warehouse and supplier data now living in the same database, the real payoff arrives: queries that answer questions a disruption-response team would actually ask. A simple ranking query — which products are moving the most — is useful on its own. But the more important artifact is a view: a saved query, vProductsbySuppliers, that joins warehouse inventory against supplier records and groups the results by supplier location. That view becomes a reusable lens on the data — the kind of object that can sit quietly behind a dashboard, or be exposed through Fabric's SQL analytics endpoint and GraphQL API for a front-end app to query directly. It's the difference between running a report once and building infrastructure a team can lean on every day. The Parts You Don't Have to Build Perhaps the most understated part of the whole exercise was everything I didn't have to configure. Fabric's SQL database comes with a built-in Performance Dashboard tracking CPU consumption, connection counts, and allocated storage, plus automatic indexing that tunes itself based on query patterns over time. Backups happen on a schedule without anyone setting up a maintenance window. For a demo project this is a nice-to-have; for a production disruption-response system running around the clock, it's the difference between a database that needs a dedicated administrator and one that mostly looks after itself. Querying Through the SQL Analytics Endpoint Every SQL database in Fabric quietly maintains a second identity: the SQL analytics endpoint. It's a read-only, automatically synchronized mirror of the same data, purpose-built for analytical querying rather than transactional writes. Practically speaking, that means I could point ordinary T-SQL at it — no different syntax, no separate connection ceremony — and start layering real analytical logic on top of the operational tables without ever putting extra query load on the transactional database itself. That separation turned out to be the right place to build out the analytical model properly. Rather than one flat query, I created three views, each with a distinct job: vProductsBySupplier rolls up order quantities by product and supplier; vSalesByDate breaks sales volume down by year and month; and vTotalProductsByVendorLocation sits on top of the first view and groups everything by supplier location — the exact cut a disruption-response team needs when a single region goes offline. Building views on top of other views felt like the right instinct here rather than a shortcut. vTotalProductsByVendorLocation didn't need to know anything about sales order headers or line-item details — it just needed the already-summarized product-and-supplier numbers, joined once more against the warehouse table to bring location into the picture. Each layer stays simple, and each one is independently reusable. CREATE VIEW SupplyChain.vProductsBySupplier AS -- View for total products each supplier SELECT sod.ProductID , sup.CompanyName , SUM(sod.OrderQty) AS TotalOrderQty FROM SalesLT.SalesOrderHeader AS soh INNER JOIN SalesLT.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID INNER JOIN SupplyChain.Warehouse AS sc ON sod.ProductID = sc.ProductID INNER JOIN dbo.Suppliers AS sup ON sc.SupplierID = sup.SupplierID GROUP BY sup.CompanyName, sod.ProductID; GO CREATE VIEW SupplyChain.vSalesByDate AS -- Product Sales by date and month SELECT YEAR(OrderDate) AS SalesYear , MONTH(OrderDate) AS SalesMonth , ProductID , SUM(OrderQty) AS TotalQuantity FROM SalesLT.SalesOrderDetail AS SOD INNER JOIN SalesLT.SalesOrderHeader AS SOH ON SOD.SalesOrderID = SOH.SalesOrderID GROUP BY YEAR(OrderDate), MONTH(OrderDate), ProductID; GO CREATE VIEW SupplyChain.vTotalProductsByVendorLocation AS -- View for total products by each supplier by location SELECT wh.SupplierLocationID AS 'Location' , vpbs.CompanyName AS 'Supplier' , SUM(vpbs.TotalOrderQty) AS 'TotalQuantityPurchased' FROM SupplyChain.vProductsBySupplier AS vpbs INNER JOIN SupplyChain.Warehouse AS wh ON vpbs.ProductID = wh.ProductID GROUP BY wh.SupplierLocationID, vpbs.CompanyName; GO From Views to Visuals: Building the Power BI Report Views are only half the story — someone still has to look at them. Fabric makes the handoff from database to BI tool almost seamless, but there's a small manual step worth calling out: grabbing the connection string. Under the database's Settings, the connection string contains both the server name and the database name buried inside a longer string, and it's these two values — not the full string — that external tools like Power BI Desktop or SQL Server Management Studio actually want. Inside Fabric itself, though, the path to a report is more direct. Selecting New semantic model over the SQL analytics endpoint pulls in the tables and views I'd built — including all three SupplyChain views — and wraps them in a data model describing how everything relates. One default was worth overriding immediately: the Location field on vTotalProductsByVendorLocation is a location identifier, not a quantity, so it needed Summarize by set to None. Otherwise Power BI happily sums location IDs together into a meaningless total, which is a small trap worth knowing about before it shows up in a report. Why This Pattern Matters Fabric collapses a workflow that traditionally spans several tools — a database server, an ETL tool, a BI platform, a monitoring dashboard — into one connected environment. For a supply chain disruption app specifically, that matters because disruptions don't wait for data to be reconciled across systems. The faster raw supplier and inventory data can be joined, queried, and visualized, the faster a team can answer the question that actually matters in a crisis: what's affected, and what do we do next? Building this out end-to-end — workspace, database, ingested and generated data, a layered set of analytical views, and a working Power BI report — took a single sitting. That speed is really the headline feature. The tools get out of the way fast enough that most of the effort goes into modeling the problem, not the plumbing. What's Coming Next in This Series With the data foundation and the first report in place, the next posts in this series will build on top of it: Part 2 — Notebooks, DevOps, and GraphQL: exploring the data interactively in a Fabric Notebook, bringing the database schema under source control with Azure DevOps, and standing up a GraphQL API on top of the vProductsbySuppliers view. Part 3 — The Application: wiring all of it together into a working ASP.NET web app that lets a disruption-response team type in an affected location and instantly see every supplier and product count at risk. Stay tuned — the foundation and the first report are in place; next up is making the data interactive.Sorting Date & Month Columns in Descending Order in Power BI Matrix Visual
Struggling to get your months to sort correctly in descending order within a Power BI Matrix visual? You’re not alone! In this article, we’ll walk through step-by-step techniques—using a Date table, [Date Sort] column, and smart DAX—to ensure your date and month columns always appear in the correct order.Pizza Sales Report
Five business insights from data Most Pizza Selling In 16-20 Hours. Most Selling Large Pizza Name of Thai Chicken. At 8242, Friday Had the Highest Sum Of Quantity And Was 36.57% Higher Than Sunday, Which Had The Lowest Sum Of Quantity At 6035. Quarter 2 Has Increase Pizza Quantity. Quarter 4 Has Decrease Pizza Quantity eyJrIjoiOTA1OGYwZWYtMjVhNS00NTY0LTgzNmYtNGJhZWJkNGE1ZTViIiwidCI6ImJmYjZiODdiLTViODUtNDkxMS1hYWMxLTJkODIyMThiOGQ4ZCIsImMiOjl9ESG Risk Landscape Analysis
About the Report The ESG Risk Analysis for S&P 500 provides a data-driven assessment of Environmental, Social, and Governance (ESG) risks across leading U.S. companies. The report highlights key risk drivers, identifies high- and low-performing sectors, and evaluates company-specific exposures to ESG-related issues. Its purpose is to illuminate risk, inform action, and empower responsible leadership by integrating sustainability insights into decision-making. Key Insights: Overall ESG Risk: Most S&P 500 firms are in the Medium Risk range; a smaller group shows High or Severe risk, demanding urgent attention. Risk Components: Environmental: Elevated in Energy and Basic Materials sectors. Governance: Linked to board structure and shareholder rights. Social: Driven by labor practices, safety, and community impact. Controversies: Firms with High/Severe controversies record significantly higher risk scores. Sector Outlook: High Risk: Energy, Basic Materials, Consumer Cyclical. Lower Risk: Technology, Financials, Healthcare (with exceptions). Notable Companies: High Risk/Controversy: WFC, XOM, META, CAT. Low Risk/Controversy: XYL, WDC, WELL. Scale Factor: Large firms like Walmart and Amazon face elevated risks due to operational scale and workforce size. Benefits: Enhances transparency in corporate sustainability reporting. Enables data-driven ESG strategies and early risk mitigation. Builds investor confidence through responsible disclosure. Supports long-term value creation by linking sustainability with performance. Skills: Data Analytics · OpenAI GPT Agents · DAX · Microsoft Power BI · Data Modeling · Environmental, Social, and Governance (ESG) · SQL · Microsoft Azure · XGBoost eyJrIjoiZTZlOWQ0OTktZWRjYi00Nzc4LTllZjYtOTdiOWU3NzQxYmYyIiwidCI6IjkyNTcwMDE0LWZmM2QtNDAxMC04MTNkLTQxM2YwZmY5OWQ5MiJ9Mastering Advanced Regression for Data Science in Microsoft Fabric
In this edition, we’re exploring two regression techniques that every data professional eventually bumps into when the simple models stop telling the full story. You’ll get a clear sense of what quantile regression actually solves, especially when your data behaves in unpredictable or uneven ways. By the time you’re done, you’ll feel more confident choosing the regression approach that truly fits the question you’re trying to answer, instead of defaulting to whatever is familiar.
