How to find best-selling items in Power BI using MAXX

You don’t need 100 DAX functions. Just these 10 can cover 90% of your analysis in Power BI 1. CALCULATE() Most powerful DAX function Changes the context of a calculation Example: Sales2024 = CALCULATE(SUM(Sales[Amount]), Sales[Year] = 2024) 2. SUM() / AVERAGE() / COUNT() Basic aggregation functions Frequently used in KPIs and dashboards Example: Total Sales = SUM(Sales[Amount]) 3. FILTER() Returns a table that you can use inside CALCULATE Helps define complex filter logic Example: HighSales = CALCULATE(SUM(Sales[Amount]), FILTER(Sales, Sales[Amount] > 10000)) 4. ALL() / REMOVEFILTERS() Removes filters from a table/column Essential for calculating % of total or grand totals Example: SalesPct = DIVIDE(SUM(Sales[Amount]), CALCULATE(SUM(Sales[Amount]), ALL(Sales))) 5. DATESYTD(), DATESMTD(), DATESQTD() Time intelligence functions Useful for year-to-date, month-to-date calculations Example: SalesYTD = TOTALYTD(SUM(Sales[Amount]), Dates[Date]) 6. DIVIDE() Safe division (avoids divide-by-zero errors) Preferred over / operator Example: ProfitMargin = DIVIDE([Profit], [Revenue]) 7. IF() / SWITCH() Conditional logic Used to create calculated columns or flags Example: CategoryFlag = IF(Sales[Amount] > 10000, "High", "Low") 8. EARLIER() Used in row context to refer to outer row values Mostly used in calculated columns Example: ranking, previous row comparison 9. RANKX() Ranks values across a table or category Used for top N analysis Example: SalesRank = RANKX(ALL(Products), [Total Sales]) 10. RELATED() / RELATEDTABLE() Used to fetch data from related tables Helpful in star schema models Example: CustomerRegion = RELATED(Customer[Region]). .

A Single Power BI Function Saved an Entire Project! We once inherited a Power BI project where a Sales Summary Table displayed: 📅 Monthly Sales 📆 Quarterly Sales 📈 Yearly Sales Sounds simple, right? Except there was one major issue. The Yearly Sales value was supposed to change only when the “Year” filter was applied on the dashboard… But it kept changing with every filter, month, quarter, region, or even product category! Since we didn’t build the model from scratch, we couldn’t redesign all the measures or visuals. We needed a surgical fix, and that’s when we discovered the magic of ALLSELECTED()’s quiet cousin: 👉 ALLEXCEPT() 🧠 The Concept ALLEXCEPT() removes all filters in a table — except the ones you specify to keep. It’s like saying: “Ignore all filters except for these specific columns.” So, in our case, we told Power BI: “Keep the Year filter, but ignore everything else!” ⚙️ The Fix (Implementation) Here’s the measure that saved our project: Yearly Sales = CALCULATE( SUM(Sales[Amount]), ALLEXCEPT(Date, Date[Year]) ) This single line ensured: ✅ Monthly or Quarterly slicers no longer messed with Yearly totals. ✅ Only the “Year” slicer on the report page could impact the Yearly Sales value. ✅ No need to rewrite or rebuild the entire model. 🏁 Takeaway When working with pre-built Power BI models or complex dashboards: 🔹 ALLEXCEPT() is your best friend for controlling filter behaviour. 🔹 It gives you the granular control you need over context without heavy redesigns. #PowerBI #DAX #DataAnalytics #BusinessIntelligence #DataVisualization

Understanding Single vs Bidirectional Relationships in Power BI In Power BI data modeling, relationships between tables define how filters and data flow. A common scenario in larger models is when multiple fact tables (like Internet Sales and Reseller Sales) share dimension tables (such as Product, Date, Currency, Promotion, and Sales Territory) — while also having exclusive dimensions (like Customer for Internet Sales and Reseller/Employee for Reseller Sales). By default, these relationships are single-directional, meaning filters flow from dimensions to facts — and that’s usually the best practice. Why avoid bidirectional cross-filtering on shared dimensions? Because it can unintentionally create complex and confusing filter contexts. For instance, enabling bidirectional filtering between Promotion and Reseller Sales could cause Internet Sales results to be affected by Reseller or Employee filters — which users don’t expect. 💡 If bidirectional behavior is needed for a specific measure, use the CROSSFILTER() DAX function instead. ✅ When to use bidirectional filtering safely: Between exclusive dimensions and their fact tables (e.g., Customer ↔ Internet Sales, Reseller ↔ Reseller Sales) to enable intuitive filtering like “count of resellers by region.” ⚠️ Power BI automatically blocks bidirectional relationships that create ambiguity — such as multiple filter paths to another fact table (e.g., Product → Reseller Sales → Sales Territory → Sales Plan). Have you ever faced unexpected results due to bidirectional relationships in Power BI? Do you prefer using CROSSFILTER() or enabling bidirectionality directly? How do you manage shared dimensions across multiple fact tables in your models? #PowerBI #DataModeling #DAX #BusinessIntelligence #Analytics #DataEngineering #PowerBIDesign #DataVisualization

Today's Takeaway : Relationship & Filter Functions : In Power BI, relationships and filters define how data flows from one table to another. But what if you need to override or change that behavior? Relationship & Filter Functions in DAX give us the power to change/reshape filter context . Why They Matter These functions are essential when: 🌀 Relationships are ambiguous 📅 You need to filter by multiple date fields (e.g., order date vs ship date) 📊 The default model logic doesn’t meet business needs 🔸 RELATED() Pulls a value from the one-side of a relationship into the many-side. 💡 Use it to bring lookup values into a fact table (like product name into sales). 🔸 RELATEDTABLE() Returns a table of rows from many side of relationship into one side of relationship. 💡 Example: Count how many orders a customer has. 🧠 Works great with CALCULATE() and COUNTROWS(). 🔸 USERELATIONSHIP() Activates an inactive relationship for a specific measure. 💡 Use it when you have multiple relationships between two tables (e.g., order date vs ship date). 🧠 Must be used inside CALCULATE(). 🔸 CROSSFILTER()  To Changes or disables filter direction between two columns. 💡 Useful for resolving ambiguous or circular relationships. 🧠 Must be used inside CALCULATE(). 📌 Reminder: These functions only work when a relationship exists between the tables. Have you used USERELATIONSHIP() to solve a tricky time intelligence problem? Or CROSSFILTER() to untangle a messy model? Thanks for you support Rakesh Nag, Vinayak Kadam, Codebasics #PowerBI #DAX #DataModeling #Analytics #BusinessInteigence #MicrosoftPowerBI #DataContext #DAXTips #FilterLogic

Why separating “Dim” and “Fact” tables are important in Power BI Many people start with a single table. It works... until it doesn’t. As your model grows, you realise data lives in two worlds: 1️⃣ Fact tables They’re the events: every transaction or movement that happens over time. Examples: sales, orders, production, consumption. They contain dates, quantities, values, and keys that connect to dimensions. 2️⃣ Dimension tables They’re the context: the labels that give meaning to those events. Examples: materials, customers, sales orgs, plants, calendar. They’re what you use to filter, group, and explain. The secret is in how you connect them: • Dimension tables stay on the one side, with no duplicates • Fact tables stay on the many side • Filter direction flows from Dim to Fact Real example: I had to compare monthly forecasts with daily customer orders. So I built a Dimension “Date × SalesOrg × Material” and connected both fact tables (Forecast and Orders) to it. Without that layer, Power BI was summing everything as if all materials and orgs were the same. In the end, a solid model is less about formulas and more about structure. When your relationships are right, DAX almost writes itself.

🎉 Big news for Power BI users and data pros! Microsoft just launched Calendar-Based Time Intelligence in preview — think custom fiscal calendars, week-level analysis, and new DAX functions to match. 📌 With this feature, you can: Define any calendar (fiscal, retail, shifted, etc.) Use enhanced DAX (TOTALWTD, PREVIOUSWEEK, etc.) Work with sparse date tables (no need for full continuous date range) 🛠️ How to Try It (Preview Mode) 1. In Power BI Desktop, go to File → Options and settings → Options → Preview features Turn on “Enhanced DAX Time Intelligence” (or “Calendar-based time intelligence”). 2. Once enabled, right-click your date (or calendar) table → Calendar options Here, you can create/edit calendars, map categories, and validate them. 3. Define categories like Year, Quarter, MonthOfYear, Week, etc., tagging them to respective columns. Validate the mapping. 4. Write your DAX using the custom calendar. For example: Sales MTD = TOTALMTD ( [Total Sales], 'GregorianCalendar' ) Sales WTD = TOTALWTD ( [Total Sales], 'GregorianCalendar' ) Sales Same Fiscal Q-LastYear = CALCULATE( [Total Sales], SAMEPERIODLASTYEAR ( 'FiscalCalendar' ) ) 5. Visualize and compare: You might use a line chart or bar chart showing Total Sales and Sales WTD side by side, or a matrix showing metrics by week/month. Want to try this yourself? Just enable “Enhanced DAX Time Intelligence” in preview features, define a calendar, and write DAX using that calendar. I’m excited to explore this more Have you tried it yet? What use case are you thinking of?

Todays Takeaway : Mastering VALUES() vs DISTINCT() in Power BI DAX Understanding the subtle difference between VALUES() and DISTINCT() is important. VALUES() 🧮 Returns unique values (includes blanks). ✅ Understands filter context. ✅ Can modify it — but only when used inside CALCULATE(). Product Sales % = DIVIDE(   CALCULATE(SUM(Sales[Amount]), VALUES(Sales[Product])),   CALCULATE(SUM(Sales[Amount]), ALL(Sales[Product])) ) DISTINCT() Returns unique values from a column(removes blanks ). ✅ Understands the current filter context (respects slicers & visuals). ❌ Cannot modify it. Unique Customers = COUNTROWS(DISTINCT(Sales[Customer])) ➡️ Counts distinct customers based on active filters (like region or date). 💼 Real Project Use 📊 In a Retail Dashboard: Use DISTINCT() for unique customer count or clean lists. Use VALUES() inside CALCULATE() → for dynamic KPIs, ranking, or sales contribution %. 💡 Pro Tip 🔸 Use DISTINCT() when you just need unique values 🔸 Use VALUES() when you need DAX to interact dynamically with your filter context (especially in CALCULATE() or FILTER()). Thank Yoy for your support Rakesh Nag, Dhaval Patel, Hemanand Vadivel, Codebasics, Vinayak Kadam, Rishabh Mishra #PowerBI #DAX #DataAnalytics #BusinessIntelligence #LearningPowerBI #DataModeling #PowerBIDAX

🎯 𝗦𝗶𝗻𝗴𝗹𝗲-𝗗𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝘃𝘀 𝗕𝗶-𝗗𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗙𝗶𝗹𝘁𝗲𝗿𝘀 🎯 When I first started building data models in Power BI, I used to ignore the tiny arrow on the relationship line. 😅 Little did I know — that arrow decides how your data flows and how your visuals behave. - 𝗟𝗲𝘁’𝘀 𝘀𝗶𝗺𝗽𝗹𝗶𝗳𝘆 👇 🔹 𝗦𝗶𝗻𝗴𝗹𝗲-𝗗𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗙𝗶𝗹𝘁𝗲𝗿 ➡️ Data filters in one direction only — usually from Dimension ➜ Fact table. ✅ Example: Your “Date” table filters your “Sales” table. Change the year, and only sales update. 🧠 Best for Star Schemas where relationships are clear and one-way. 👉 Think of it like: “The master table drives the report.” 🔹 𝗕𝗶-𝗗𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗙𝗶𝗹𝘁𝗲𝗿 ↔️ Data filters both ways — from Dimension to Fact and Fact to Dimension. ✅ Example: If you select a Product in “Sales”, the “Product” table filters too. 🧠 Useful when both tables need to interact dynamically. 👉 Think of it like: “Both tables talk to each other.” 💡 𝗧𝗶𝗽: Use Single Direction by default. Switch to Bi-Directional only when you need cross-filtering between related tables (like Many-to-Many). 🎯 𝗜𝗻 𝘀𝗵𝗼𝗿𝘁: ➡️ 𝗦𝗶𝗻𝗴𝗹𝗲 𝗗𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻 — One-way control (clean, simple, safe) ↔️ 𝗕𝗶-𝗗𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻𝗮𝗹 — Two-way interaction (powerful but risky) 💬 𝘏𝘢𝘷𝘦 𝘺𝘰𝘶 𝘦𝘷𝘦𝘳 𝘧𝘢𝘤𝘦𝘥 𝘸𝘦𝘪𝘳𝘥 𝘳𝘦𝘴𝘶𝘭𝘵𝘴 𝘣𝘦𝘤𝘢𝘶𝘴𝘦 𝘰𝘧 𝘣𝘪-𝘥𝘪𝘳𝘦𝘤𝘵𝘪𝘰𝘯𝘢𝘭 𝘧𝘪𝘭𝘵𝘦𝘳𝘴? 𝘏𝘰𝘸 𝘥𝘪𝘥 𝘺𝘰𝘶 𝘧𝘪𝘹 𝘪𝘵? 👇 #powerbi #datamodelling #dataanalytics

Building Smarter Business Forecasts in Tableau: A Practical Walkthrough Introduction Every business wants to know one thing—what’s next? Whether it’s quarterly sales, marketing ROI, or demand fluctuations, forecasting turns hindsight into foresight. With the right data and tools, predictions become a powerful advantage rather than a guessing game. Tableau simplifies this process by combining visual analytics with statistical modeling. Its built-in forecasting feature—powered by the Holt-Winters exponential smoothing algorithm—enables users to project future outcomes with just a few clicks, while still offering deep customization for advanced users. In this guide, we’ll explore how to use Tableau for business forecasting—from understanding the fundamentals of trend, seasonality, and error metrics to customizing models that deliver actionable insights. Understanding Forecasting in Tableau Forecasting uses historical data patterns to estimate future outcomes. In business, this could mean projecting next quarter’s revenue, website traffic, or customer demand https://lnkd.in/gjRu5kEQ

Building Smarter Business Forecasts in Tableau: A Practical Walkthrough Introduction Every business wants to know one thing—what’s next? Whether it’s quarterly sales, marketing ROI, or demand fluctuations, forecasting turns hindsight into foresight. With the right data and tools, predictions become a powerful advantage rather than a guessing game. Tableau simplifies this process by combining visual analytics with statistical modeling. Its built-in forecasting feature—powered by the Holt-Winters exponential smoothing algorithm—enables users to project future outcomes with just a few clicks, while still offering deep customization for advanced users. In this guide, we’ll explore how to use Tableau for business forecasting—from understanding the fundamentals of trend, seasonality, and error metrics to customizing models that deliver actionable insights. Understanding Forecasting in Tableau Forecasting uses historical data patterns to estimate future outcomes. In business, this could mean projecting next quarter’s revenue, website traffic, or customer demand https://lnkd.in/gjRu5kEQ