I recently tried an experiment:

Could I use Claude Code to build a Power BI executive dashboard without manually creating every measure, visual and formatting element?

Not just asking AI to explain DAX.

Not copying and pasting code between ChatGPT and Power BI.

I wanted the AI agent to actually work with the Power BI project itself.

So I gave Claude Code access to a Power BI project and asked it to turn an existing report into a clean, executive-ready dashboard.

The result gave me a very different perspective on where Power BI development is heading.

We’ve Been Using AI in Power BI the Wrong Way

Most analysts already use AI.

But usually, the workflow looks something like this:

“Write a DAX measure for YoY growth.”

Copy » Open Power BI » Paste » Error » Go back to AI » Copy again

Then manually create the visual, configure it, format it and position it.

AI is helping, but we are still doing most of the development ourselves.

I wanted to test a different model.

Instead of asking:

“How do I build this?”

I wanted to ask:

“Can you help me build this?”

That’s a subtle difference, but I think it’s an important one.

From AI Assistant to AI Agent

Using the Power BI PBIP project format, Claude Code and Power BI authoring tools, the AI could interact much more directly with the project.

Claude was able to understand the existing structure and help create the new executive summary.

It worked on:

• DAX measures

• Data model understanding

• KPI cards

• Monthly trend analysis

• Waterfall analysis

• Country performance tables

• Report formatting

• Custom theme

• Visual positioning and layout

But one of my favourite parts wasn’t actually the DAX or the visuals.

It was the workflow.

I Asked Claude to Understand the Business First

Instead of immediately telling Claude:

Create four KPI cards, one line chart and one waterfall.

I wanted the process to start with the business objective.

What does an executive actually need from this page?

What questions should the dashboard answer?

What deserves attention?

Only then should we decide which visuals belong on the page.

The workflow became something closer to:

This is much closer to how a good BI project should work.

And it points to something bigger than simply using AI to generate DAX.

Did Claude Build Everything Perfectly?

No.

And I deliberately show that in the video.

There were sorting issues.

Some formatting wasn’t right.

Certain visual decisions needed adjustment.

I made manual changes as well.

There were moments where the output needed debugging and another prompt.

But that’s precisely why I found the experiment useful.

I’m less interested in polished demos where someone enters one prompt and magically gets a perfect dashboard.

That’s not how real analytics projects work.

The more useful question is:

How much repetitive Power BI development can an AI agent take away from an analyst?

And based on what I’m seeing, the answer is becoming increasingly interesting.

Does This Mean Power BI Developers Won’t Be Needed?

I don’t think that’s the right conclusion.

Instead, I think what makes a good Power BI developer valuable is changing.

Consider DAX.

If AI becomes extremely good at generating DAX, memorising hundreds of functions becomes less important.

But understanding whether the generated measure is correct becomes more important.

You still need to know:

• Is the data model designed correctly?

• Is the filter context behaving as expected?

• Is this KPI actually meaningful?

• Does this visual answer the business question?

• Are we comparing the correct periods?

• Can we trust the result?

• Is the dashboard helping someone make a decision?

AI can generate things incredibly quickly.

But generating something and generating the right thing are two very different problems.

That’s why I think the strongest analytics professionals over the next few years will combine:

Business Understanding + Data Modelling + Analytics + AI Agents + Judgement

Power BI Development Is Becoming More Agentic

Traditionally, our workflow has been:

Requirements → Data → Model → DAX → Visuals → Formatting → Testing

AI initially helped around the edges.

Need SQL? Ask AI.

Need DAX? Ask AI.

Need Power Query? Ask AI.

Need documentation? Ask AI.

But agentic tools introduce another possibility.

Instead of AI sitting outside Power BI and giving us snippets, the agent can increasingly participate in the development process itself.

That could eventually make the workflow look more like:

Business Problem → Analyst + AI Agent → Analytics Solution

The analyst isn’t removed from the process.

The analyst moves up the value chain.

Less time manually configuring things.

More time understanding the business, asking better questions, designing the solution and validating what the AI produces.

That’s the part of AI + BI that I’m most interested in exploring.

🎓 Want to Learn This Yourself?

I’m launching my new practical course: Agentic Power BI.

You’ll build a complete AI Business Analyst project using:

Power BI → Microsoft Fabric → AI-Ready Semantic Model → External Data → Business Context → AI Agent

This isn’t another “build a dashboard” course. The goal is to give you a portfolio-ready project and practical AI + Power BI skills you can demonstrate in your current role or your next interview.

🚀 First 50 Students: $99 AUD

Regular price: $199 AUD → Launch price: $99 AUD

Think about the economics.

A $5,000 salary increase is ~$96/week.
A $10,000 salary increase is ~$192/week.

The course costs $99 once.

Of course, no course can guarantee you a promotion or a new job. But if these skills help you stand out in one interview, take on higher-value work, or position yourself for your next opportunity, the potential upside can be far greater than the cost of learning them.

The bigger cost may be waiting while the skills employers expect continue to change.

👉 GET AGENTIC POWER BI FOR $99

Launch pricing is available to the first 50 students only.

👋 Want to Talk 1:1?

Courses aren’t always the right answer.

Sometimes you need someone to look at your specific situation.

I also offer a limited number of 1:1 mentorship sessions for people working in or moving toward data and analytics.

Depending on where you are in your journey, we can work on:

• Power BI / Data Analytics career direction

• Your learning roadmap

• Resume and LinkedIn positioning

• Portfolio and project strategy

• Interview preparation

• Power BI and Microsoft Fabric skills

• Moving from traditional analytics toward AI-enabled analytics

The session is focused on your situation and your next steps, rather than following a predefined curriculum.

👉 BOOK A 1:1 MENTORSHIP SESSION

If you work with Power BI, Microsoft Fabric, data analytics or AI, subscribe to Analytical Guy — there’s a lot more coming.

And I’d love to hear your view:

If an AI agent could take over ONE part of your current Power BI workflow, what would you give it?

Cheers,
AJ
Perth, Australia
admin@analyticalguy.tech

NEW: Agentic AI for Power BI Course
AI is changing Power BI — and the next step is learning how to work with AI agents, not just dashboards.
I've just launched my new Agentic AI for Power BI course, designed to help Power BI professionals become AI-ready and start building with AI agents.

👉 Get the course here: https://academy.analyticalguy.tech/agentic-power-bi

For years, the analytics workflow looked something like this:

Data → SQL/Python → Dashboard → Analyst → Business User

The analyst sat in the middle.

We extracted the data.
Cleaned it.
Modelled it.
Built dashboards.
Found insights.
Explained those insights to the business.

But AI is starting to change this workflow.

With AI agents, semantic models, natural-language analytics, Microsoft Fabric and increasingly autonomous analytical systems, business users may no longer need an analyst for every question.

They’ll increasingly be able to simply ask:

“Why did sales drop last month?”

And an AI agent could potentially:

→ Query the semantic model
→ Analyse the relevant data
→ Investigate possible drivers
→ Compare regions/products/customers
→ Summarise the findings
→ Recommend what to investigate next

So does that mean Data Analysts are going away?

I don’t think so.

If you want to skip reading and watch the video instead:

But I do think the traditional definition of a Data Analyst is going to change.

The valuable analyst of the next few years won’t just be the person who knows the most SQL syntax, Python libraries or Power BI features.

It will be the person who understands:

Business + Data + AI

That’s also why I don’t believe you should learn SQL, Python and Power BI equally in 2026.

The question shouldn’t be:

“How do I become an expert in every analytics tool?”

It should be:

“What combination of skills helps me solve real business problems in an AI-first analytics world?”

Because AI can increasingly help you write the SQL, generate Python, create DAX and even build parts of a report.

But someone still needs to understand:

• What the business is actually trying to solve

• Whether the data can be trusted

• How the semantic model should be designed

• Which metrics actually matter

• Whether the AI’s answer makes business sense

• How AI agents should interact with enterprise data

• How insights translate into decisions

That, in my opinion, is where the opportunity is.

I recently made a video sharing my perspective on the Future of Data Analytics in the AI Era, including what I think Data Analysts, BI Developers and Power BI professionals should start learning now.

🎥 Watch: Future of Data Analytics in the AI Era

[ADD YOUR YOUTUBE VIDEO LINK]

The goal isn’t to compete with AI.

It’s to become the person who knows how to use AI to solve business problems.

I’m curious what you think:

Will AI replace a significant part of the traditional Data Analyst role — or simply create a more powerful version of it?

Email me your concerns, I read every email. Let’s solve each others problems.

Cheers,
Analytical Guy
https://analyticalguy.tech

And instead of giving you another generic list of topics from the Microsoft syllabus, I wanted to share my actual experience.

What I studied » What helped » What I would do differently.

And most importantly — how I would prepare if I had to take DP-600 again today.

If you’re coming from a Power BI background and moving into Microsoft Fabric, this is especially for you.

First: Is DP-600 Difficult?

My answer?

Yes — but probably not for the reason you think.

DP-600 isn’t just a Power BI exam.

If you’ve been working with Power BI for years, you’ll already be comfortable with things like:

• Data modelling

• DAX

• Power Query

• Semantic models

• Report development

• Security

But DP-600 takes you beyond that.

You also need to understand the broader Microsoft Fabric ecosystem.

That means concepts like:

OneLake → Lakehouse → Warehouse → Notebooks → Spark → Dataflows Gen2 → Pipelines → Semantic Models → Power BI

This is where I think many Power BI professionals underestimate the exam.

If you want to watch the video instead of reading this post:

My DP-600 Preparation Strategy

If I were starting again, I would divide my preparation into four stages.

Stage 1: Understand Microsoft Fabric

Before worrying about exam questions, understand what Fabric actually is.

Don’t try to memorise every button in the interface.

Instead, understand the architecture.

Ask yourself:

If a company gives me data from SQL, Excel, APIs and other systems — how would I build an analytics solution using Fabric?

You should understand where each Fabric workload fits.

For example:

Data Factory
→ Data ingestion and orchestration

Data Engineering
→ Spark, notebooks and transformations

Data Warehouse
→ SQL-based analytical workloads

Power BI
→ Semantic models, DAX and reporting

OneLake
→ The common storage layer connecting 
everything together

Once this architecture makes sense, a lot of DP-600 concepts become much easier.

Stage 2: Don’t Ignore Your Power BI Fundamentals

This is particularly important.

Sometimes when preparing for a new certification, we spend so much time learning the new technology that we forget the fundamentals.

DP-600 still expects you to understand analytics properly.

Make sure you’re comfortable with:

• Star schema

• Fact and dimension tables

• Relationships

• DAX

• Filter context

• Power Query

• Semantic models

• Row-level security

• Performance optimisation

Don’t just know how to create these things.

Understand why you would choose one approach over another.

That’s much closer to how certification questions are framed.

Stage 3: Get Hands-On With Fabric

This was one of the most important parts for me.

Reading documentation is useful.

Watching videos is useful.

But at some point you need to actually open Microsoft Fabric and build something.

Create a small project.

It doesn’t need to be complicated.

For example:

Source Data
↓
Fabric Pipeline / Dataflow Gen2
↓
Lakehouse
↓
Bronze → Silver → Gold
↓
Semantic Model
↓
Power BI Report

Then experiment.

Create a notebook.

Write some Spark.

Create a Warehouse.

Build a pipeline.

Create relationships.

Try Direct Lake.

Configure security.

Break something.

Fix it.

You’ll remember far more from doing this than from reading the same documentation five times.

Stage 4: Use the Microsoft Study Guide

This sounds obvious, but it’s important.

The official DP-600 study guide should be your checklist.

Go through every major skill measured in the exam and ask:

“Could I explain this concept to someone without looking it up?”

If the answer is no, that’s probably an area you need to revisit.

I wouldn’t randomly consume DP-600 content for weeks.

I’d use the official syllabus as the structure and fill my knowledge gaps around it.

The Biggest Advantage Power BI Users Have

If you’re already a Power BI developer, you’re not starting from zero.

That’s important.

You already understand a large part of the analytics layer.

Your biggest job is connecting your existing Power BI knowledge to Fabric.

Think of it like this:

Traditional Power BI mindset vs Fabric mindset

You’re essentially expanding your view of the analytics architecture.

One Mistake I Would Avoid

Trying to memorise everything.

Fabric is huge.

You don’t need to become an expert in every Fabric workload before taking DP-600.

Instead, focus on understanding:

What does this feature do?

When would I use it?

Why would I choose it over another option?

How does it connect with the rest of Fabric?

That level of understanding is much more valuable than memorising menus and screenshots.

What I Would Do 7 Days Before the Exam

If I had one week remaining, I wouldn’t spend it learning dozens of completely new topics.

I would use it for consolidation.

I’d revisit the official DP-600 skills outline and identify my weakest areas.

Then I’d spend most of my time on:

1. Fabric architecture

Understand how the different workloads fit together.

2. Lakehouse vs Warehouse

Know when and why you would choose each.

3. Data ingestion and transformation

Pipelines, Dataflows Gen2, notebooks and Spark.

4. Semantic models

Relationships, DAX, security and optimisation.

5. Direct Lake

Understand how it works and where it fits.

6. Scenario-based questions

Instead of memorising definitions, practise choosing the right solution for a business requirement.

What About Practice Questions?

Practice questions can be useful.

But I wouldn’t use them just to memorise answers.

For every question you get wrong, ask:

Why was my answer wrong?

And then:

Why is the correct option better?

That second question is where the learning happens.

I would prioritise Microsoft’s official learning and assessment resources and then use my own notes/question bank to identify gaps.

My Biggest Takeaway From DP-600

Passing DP-600 isn’t really about memorising Microsoft Fabric.

It’s about learning to think like an Analytics Engineer.

You’re no longer thinking only about:

“How do I build this Power BI report?”

You’re thinking:

“How should the data get into the platform?”

“Where should it be stored?”

“How should it be transformed?”

“How should the analytical model be designed?”

“How should users securely consume it?”

That’s a much bigger mindset shift.

And personally, I think that’s the real value of preparing for DP-600.

Should You Take DP-600?

If you’re already working with Power BI and want to move deeper into Microsoft Fabric, I think DP-600 makes a lot of sense.

Especially if you’re trying to move from:

Power BI Developer → Analytics Engineer

or

Data Analyst → Microsoft Fabric Analytics Engineer

Don’t take the certification just to add another badge to LinkedIn.

Use it as an excuse to actually understand the platform.

The certificate is useful.

The knowledge behind it is much more valuable.

I Recorded My Full DP-600 Journey 🎥

I’ve also created a YouTube video where I explain how I prepared for DP-600, my experience with the exam, and what I recommend you focus on.

If you’re currently preparing for DP-600, watch that alongside this guide.

And if you’re coming from Power BI and trying to understand Microsoft Fabric, that’s exactly the journey I’m documenting on Analytical Guy.

More Fabric, Power BI and Analytics content coming soon.

— AJ
Analytical Guy
www.AnalyticalGuy.Tech

Do I really need to learn all of this?

Lakehouse. Warehouse. OneLake. Data Factory. Spark. Notebooks. Real-Time Intelligence. Data Engineering...

It can feel like Microsoft took Power BI and suddenly added 20 new things you need to understand.

But here’s the good news:

You don’t need to learn everything at once.

And if you already know Power BI, you’re actually much closer to understanding Microsoft Fabric than you might think.

I recently created a 20-minute introduction to Microsoft Fabric specifically for Power BI users.

If you want to watch the video and skip reading:

The easiest way to understand Fabric

Forget all the product names for a moment.

Think about what normally happens before your Power BI report exists.

A company might have data sitting in:

• Excel files

• SQL databases

• ERP systems

• CRM systems

• APIs

• Cloud applications

• Streaming/real-time sources

As a Power BI developer, you often enter the picture somewhere near the end.

You connect to the data » Transform it » Build your semantic model » Write DAX » Create reports » Publish

But someone still needs to ingest, store, transform, engineer, govern and serve that data before analytics can happen.

That’s where Microsoft Fabric becomes interesting.

Instead of treating all of these as completely separate worlds, Fabric brings much of the analytics journey into one platform.

Power BI is not disappearing

This is an important distinction.

You aren’t learning Fabric instead of Power BI.

Power BI is a core workload within Microsoft Fabric.

Think of it more like expanding your field of view.

You might start here:

Data → Power BI → Dashboard

Then gradually understand the bigger picture:

Source Systems → Data Factory → OneLake → Lakehouse/Warehouse → Semantic Model → Power BI

And suddenly you’re not just thinking:

“How do I build this dashboard?”

You’re thinking:

“How should this entire analytics solution work?”

That’s a very different skill.

You don’t need to become a Data Engineer tomorrow

This is probably the biggest mistake I see people make when approaching Fabric.

They see Spark, Python, notebooks, Lakehouses and Data Engineering and think they need to master everything.

You don’t.

If you’re coming from Power BI, I’d learn Fabric outwards from what you already know.

Start with:

1. OneLake
Understand where Fabric stores data and why Microsoft describes it as OneDrive for data.

2. Lakehouse vs Warehouse
Understand why both exist and when you might use each.

3. Data ingestion
Learn how pipelines, Dataflows Gen2 and other Fabric capabilities can bring data into the platform.

4. Medallion architecture
Understand the idea behind Bronze → Silver → Gold.

5. Semantic models + Power BI
Connect everything back to the part you already understand.

Then start exploring notebooks, Spark, real-time analytics, AI and the deeper engineering capabilities.

You don’t need to learn Fabric horizontally.

Learn it from Power BI outward.

Why I think this matters for Power BI professionals

The role of a Power BI developer is changing.

Knowing how to create a dashboard is still valuable.

But increasingly, the bigger opportunity is understanding the entire data journey behind that dashboard.

Where did the data come from?

How was it ingested?

Where is it stored?

How was it transformed?

How should the architecture be designed?

How is security handled?

How does the semantic model fit into everything?

How can AI use this data?

That’s where learning Fabric can start moving you from someone who builds reports to someone who can design analytics solutions.

And I think that’s a much more valuable place to be.

I explained the whole thing in 20 minutes

I created a beginner-friendly video where I walk through Microsoft Fabric from the perspective of someone who already understands Power BI.

No attempt to teach you every Fabric feature.

The goal is much simpler:

By the end, I want you to be able to look at the Microsoft Fabric ecosystem and think:

“Okay... now I understand how all of this fits together.”

🎥 Watch: Microsoft Fabric for Power BI Users

If you’re currently a Power BI developer or analyst, I’d be interested to know:

What’s the one part of Microsoft Fabric you find most confusing right now?

Reply or leave a comment. It might become my next video.

— Analytical Guy
www.AnalyticalGuy.Tech

Every organisation hits the same wall with Power BI eventually.

Your actuals live in the data—sales, costs, headcount, whatever. But the numbers that matter most during planning season—budgets, targets, forecasts, don’t come from a database. They come from people. And Power BI, for all its power, is fundamentally read-only.

So what happens? Budgets end up scattered across a hundred spreadsheets, emailed around, versioned into oblivion, and finally re-imported by some poor analyst at 11pm. Every. Single. Cycle.

This week I built the fix: a Microsoft Fabric Data App where users type their budgets directly, and a Power BI report that shows Actual vs Budget — live, the moment they hit save. No spreadsheets. No gateway. No refresh button.

Here’s the full build. 👇

📺 Watch the full walkthrough

The idea in one sentence

The data gives you the actual. The app captures the human number the data can’t know. The report compares them.

That’s the whole pattern — and once you see it, you’ll find a dozen uses: budgets, sales targets, forecast overrides, approvals, manual corrections. Today it’s budgeting.

The architecture

Everything lives in a single Fabric workspace, entirely in the cloud:

• Fabric Data App (Rayfin) — a small web app where a planner enters a budget at month × category × store grain.

• Fabric SQL database — the app writes each budget row here.

• Lakehouse — the actuals land here from CSV.

• Power BI composite model — Imports the actuals, reads the budget table via DirectQuery, and exposes Budget, Variance, and Achievement % measures.

• The clever bit: the app reads its dropdown values (categories, stores, countries) live from the semantic model with DAX, so they’re never out of sync.

Because the budget table is DirectQuery, a new budget appears in the report without a dataset refresh. That’s the magic moment in the video.

How I built it

1. The writeback app — with Claude + VS Code

I scaffolded the app with Rayfin, Microsoft’s framework for Fabric Data Apps:

npm create @microsoft/rayfin@latest -- "FabricPlanningBudgetEntry" --template dataapp --workspace "Retail-Planning-Fabric-App"

Then I defined a single data model — a Budget entity storing month, category, store, and amount. The one design decision that pays off later: store both the key and the name (categoryKey and category), so the budget joins cleanly to the model.

A form, a couple of dropdowns fed live from the semantic model, some validation, and a “recent entries” table. Deploy is one command — rayfin up — which builds the app and provisions the SQL table in a single step.

2. Actuals into a Lakehouse

The actuals were CSVs, so I dropped them into a Fabric Lakehouse and loaded them as tables. All cloud — no gateway required.

3. The composite model

In Power BI Desktop I pointed the actuals at the Lakehouse SQL endpoint and added the Budgets table as DirectQuery from the Fabric SQL database. Keys made the relationships trivial; a generated date table kept things clean; four simple measures finished it.

4. Publish — no gateway

The part everyone gets wrong: for a cloud source, you don’t need a gateway. I set both sources as cloud connections with OAuth and published. Done.

Then the payoff: type a budget in the app → refresh the visual → Actual vs Budget updates instantly.

The gotchas that cost me hours (so they don’t cost you)

This is the part I wish someone had handed me up front:

• The dataapp template ships without rayfin/tsconfig.json. Without it, deployment silently compiles zero entities and you get an “HTTP 404 / no entities” error. Copy it from the CLI’s own template and add a references entry to the root tsconfig.

• Turn OFF Auto date/time. I genuinely hate this feature. It creates hidden date tables you never see, bloats the model, and will break your refresh the moment you add a security role.

• Clean your CSVs before loading to a Lakehouse. Strip the UTF-8 BOM and remove spaces from column headers, or “Load to Tables” rejects them with a cryptic error.

• Don’t fight the personal gateway. A composite model with a cloud DirectQuery source can’t use one — keep everything cloud and it just works.

• Lakehouse vs Dataflow Gen2: Lakehouse is simpler and faster for static files. If your source data changes regularly, use a Dataflow Gen2 so it’s a repeatable pipeline instead of you re-uploading.

• Open the app inside the Fabric portal — the embedded auth only works there, not from the raw hosting URL.

What’s next

The same pattern works for any “observed vs human” comparison. I’m planning an “API → Fabric → writeback” episode — pull live data from a public API (creator analytics vs goals, weather-driven demand planning, GitHub OKRs…) and write the human number back.

Which one should I build? Reply and tell me.

🔗 Resources: https://analyticalguy.tech/files

If this was useful, subscribe — I build Microsoft Fabric and Power BI solutions in public, gotchas and all. And forward it to the one colleague who’s still emailing budget spreadsheets. 🙂

Yours truly,
Analytical Guy
^{https://analyticalguy.tech}

Today, I’m excited to share my most comprehensive Power BI tutorial yet.

🎥 Power BI End-to-End FMCG Sales Analytics Dashboard (2.5 Hours)

This isn’t just another “build a chart” tutorial.

It’s a complete Power BI project that takes you from a raw Excel file all the way to a professional dashboard that you can confidently add to your portfolio.

Whether you’re:

• Learning Power BI for the first time

• Preparing for data analyst interviews

• Looking to switch careers into analytics

• Wanting to improve your dashboard design

...this tutorial is designed for you.

What You’ll Build

By the end of this tutorial, you’ll have a professional FMCG Sales Analytics Dashboard featuring:

More importantly, you’ll understand why each step is performed—not just copy what I’m doing.

What You’ll Learn

We cover the complete Power BI workflow:

• Importing Excel data

• Cleaning data with Power Query

• Data Modeling (Star Schema)

• DAX Fundamentals

• Business KPI Measures

• Dashboard Design Best Practices

• Creating Interactive Reports

• Publishing to Power BI Service

This is the same workflow used in many real-world Power BI projects.

Course Outline

📌 Power BI Fundamentals

📌 Understanding Business Data

📌 Power Query

📌 Data Modeling

📌 DAX

📌 KPI Development

📌 Dashboard Design

📌 AI-assisted Wireframing

📌 Publishing & Sharing

Watch the Full Tutorial

🎥 Watch on YouTube

Free Resources

I’ve also included downloadable resources so you can build everything alongside me.

• Dataset

• Power BI (.pbix) file

• Practice files

(Links are available in the YouTube comments.)

What’s Next?

Over the coming weeks, I’ll be publishing more practical content on:

• Power BI reports using AI

• Fabric Apps

• AI for Data Analysts

• Power BI for Data Engineers

• Power Query Tips

• Dashboard Design

• Microsoft Fabric

• SQL

• Career advice for aspiring analysts

If that sounds useful, consider sharing with your colleagues and friends.

Thanks for reading, and I hope this tutorial helps you build confidence with Power BI.

See you in the next one!

— Atikant Jain (Analytical Guy)

P.S. If you watch the tutorial, I’d love to know what you’d like me to cover next. Reply to this email or leave a comment on YouTube—your feedback shapes future content.

Using the Rayfin framework and Claude Code, I went from an empty folder to a live, authenticated, database-backed app in a single sitting. Auth, a real database with per-user security, and a public URL — all running inside Fabric.

Here’s the full walkthrough. 👇

What we actually built

A working To-Do app — but a real one, not a toy:

• 🔐 Microsoft sign-in (Fabric brokered auth)

• 🗄️ A real database with row-level security — every user only sees their own tasks

• ⚡ Task priorities (High / Medium / Low) added end-to-end, from the data model to the UI

• 🚀 One-command deploy to a live, shareable URL

The interesting part isn’t the app — it’s how little friction there was between idea and deployed product.

📄 Reference links:

• Microsoft Fabric → https://www.microsoft.com/microsoft-fabric

• Claude Code → https://claude.com/claude-code

• Rayfin framework docs → Rayfin docs

• Source code / repo → Github link

The part that surprised me

The whole thing is declarative. You describe your data as a class — Todo, with fields and a security policy — and Rayfin turns that into a real database table with a check constraint and per-user access enforced server-side. When I added the priority feature, I touched three files and re-ran one deploy command. That’s it.

That’s a genuinely different feeling from wiring up a backend, a database, an auth provider, and a host separately.

What’s next

Part 2 is already in the works — using Semantic Model to work on DEMAND & FORECASTING write-back feature, and a few more features that turn this from a demo into something you’d actually use. Each part builds on the last.

Subscribe to follow the series, and if you want me to cover a specific Fabric App scenario, just reply — I read every response.

💬 Building something on Fabric? Hit reply and tell me what you’re working on.
🔔 New parts drop regularly — subscribe so you don’t miss Part 2.

No dragging fields onto a canvas. No fiddling with formatting panes. I described the outcome, and Claude did the rest using Microsoft’s new agentic skills for Fabric.

The full build is in the video above. This post is the “why it matters” version — plus the one moment that genuinely surprised me.

What actually got built

Starting from a raw retail model (sales, products, stores, customers), Claude produced a 4-page Power BI report:

• Overview, Products, Stores, Customers — with a real top navigation menu

• DAX measures written from scratch — including catching that the fact table had no revenue column, so it derived sales as quantity × unit price on its own

• A custom theme, KPI cards with icons, sorted gradient charts, and a drill-down matrix

• A dynamic AI insight line — “Computers leads at 34% of sales · United States is the top market · 58.6% margin” — that recalculates when you change the year filter

All from plain-English prompts. The kind of thing that’s normally a full afternoon of clicking.

The part that sells it: what happens without the skills

Here’s the demo that made the concept click for me.

I asked a plain AI — no skills loaded — to “build a Power BI page.” It confidently produced JSON that looked right… and opened broken in Power BI Desktop. Invalid visual types. Properties in the wrong place. Error boxes.

That’s the trap with AI and specialized formats: it’s confident but wrong.

The agentic skills fix exactly this. They give the model Microsoft’s actual report spec (PBIR), a validator, and — critically — the ability to reload Power BI and screenshot its own work. So it doesn’t just generate and hope. It generates, checks, sees the render, and fixes itself.

How it works (the 60-second architecture)

There are two channels working in parallel:

1. Model channel (live): Claude talks to the running Power BI Desktop model over XMLA to create measures and test DAX.

2. Report channel (files): Claude writes the report’s JSON files to disk, validates them, then reloads Desktop to render them.

Wrapping both is the loop that makes it trustworthy:

write → validate → reload → screenshot → fix → repeat

That self-correction loop is the whole difference between a party trick and something you’d actually use.

Where it got genuinely fun: conversation, not configuration

The best moments weren’t the first build — they were the follow-ups. I just talked to it:

• “Make it multi-page with a navigation menu.” → It restructured into four pages with a tab bar.

• “The year filter looks off.” → It restyled the slicer.

• “Polish the cards and add a dynamic insight.” → Bigger numbers, icons, and that live AI sentence.

And the finale: I dropped a theme file into the folder and said “use this for inspiration.” It read the palette and typography and re-skinned every page to match. Feed it your brand — or a screenshot — and it designs to your taste, not a generic template.

It felt less like using software and more like art-directing a designer who never gets tired.

The honest take

This isn’t magic, and I’m not telling you to ship AI-built reports to your CFO tomorrow. A few real caveats:

• You still need to review the DAX and the numbers — the AI is fast, not infallible.

• It works best when you can see and verify each step (the screenshot loop matters).

• It’s a collaborator, not a replacement — you’re still the analyst deciding what’s worth building.

But the direction is unmistakable. The skill of the future isn’t clicking through menus faster — it’s knowing what to ask for and how to judge the result.

The future of Power BI is agentic. And it’s already here in preview.

Watch the full build

In the video I walk through all of it end-to-end: the announcement, the “without skills” failure, setting up the plugin in Claude, the first build, the conversational refinement, and the design re-skin.

If you found this useful, subscribe — I break down AI + data workflows you can actually use, minus the hype.

What would you hand off to an AI agent first — and what would you never let it touch? Reply and tell me.

You can build a report… but is that junior or senior? You know some DAX… but is it enough to get paid more? There’s no map. So I built one.

I broke Power BI down into 6 levels and 36 skills — from “I just opened Power BI” all the way to “I design the data platform and lead the team.” Watch the full breakdown here, then scroll down and score yourself:

First, an honest disclaimer

These 6 levels (A1 → C2) are my own framework — a simple way to show how Power BI skills build up in complexity and what employers actually expect at each stage. They are not an official Microsoft classification or certification. Think of it as a map, not a rulebook.

The 6 Levels (and the 36 skills)

🟥 A1 — Newbie (you’ve opened Power BI)
Get Data · Core Visuals · Filters & Slicers · Basic Power Query · Publish to the Service · Dashboards vs Reports

🟧 A2 — Learner (you can shape data)
Power Query transforms · Data cleaning · Relationships · Basic DAX · Report design · Q&A & Smart Narrative

🟨 B1 — Analyst (you can model & tell stories)
Star schema · Date table & time intelligence · CALCULATE/FILTER/ALL · Drill-through & bookmarks · AI visuals · Copilot basics

🟨 B2 — Developer (enterprise-ready & Fabric-aware)
Advanced DAX · Time intelligence · Advanced Power Query · Row-Level Security · Microsoft Fabric fundamentals · Copilot for development

🟩 C1 — Expert (you optimise & engineer at scale)
Performance tuning · DAX Studio · Calc groups & field parameters · Enterprise refresh · Fabric engineering · AI-ready semantic models

🟩 C2 — Architect (you design the platform & lead)
Tabular Editor & TMDL · Git & CI/CD · Semantic model governance · MCP & AI agents · Azure AI / AI Foundry · Solution architecture & leadership

Now score yourself — out of 36

Give yourself 1 point per skill — but only if you’ve actually done it in a real report (not just watched a tutorial). Then find your rank:

• 1–6 → Newbie

• 7–12 → Learner

• 13–18 → Analyst

• 19–24 → Developer

• 25–30 → Expert

• 31–36 → Architect

The uncomfortable truth

Most people plateau at B1 (Analyst) and stay there for years — because they can build a report, so they assume they’ve made it. But the jump from Analyst to Developer/Architect isn’t luck or years served. It’s a specific, learnable set of skills. That gap is your roadmap.

And here’s the part nobody’s talking about: levels 4–6 are the people who build the AI — the ones who make a model Copilot can actually read, and wire it up with Fabric and MCP. As AI eats the boring parts of analytics, that’s the work that stays valuable.

Get the free checklist

I turned all 36 skills into a free checklist so you can score yourself properly and track your progress level by level:

Get your free PDFs here.

Watch the full video

The video walks through every level with examples and the exact skill that gets you to the next one:

If this gave you a clearer path, subscribe — this newsletter (and my channel) is your Power BI + data-career roadmap, with a focus on breaking into data here in Australia 🇦🇺.

So — reply and tell me your score /36 and the one skill you’re learning next. I read every reply.

See you in the next one,
Analytical Guy

We’re going to build one KPI card that switches between metrics when the user clicks a button. No custom visual, no marketplace plugin — just DAX and a bit of SVG.

How to build it? (5 steps)

Step 1 — Build your base measures
Create TY and LY pairs for every metric you want to switch between. Example:

• Total Sales / Total Sales LY

• Total Quantity Sold / Total Quantity Sold LY

• Total Unique Products / Total Unique Products LY

Step 2 — Create a field parameter
Go to Modeling → New parameter → Fields and add the TY measures. Power BI auto-creates a Parameter table with a Parameter Order column (0, 1, 2…) — that’s the index we’ll use to switch.

Step 3 — Drop a button slicer
Add a Slicer visual, set it to Tile layout, and put the Parameter field in it. Clicking a button filters the parameter table to one row.

Step 4 — Write the SVG measure
Create a measure that reads Parameter[Parameter Order], picks the right TY/LY pair via SWITCH, formats the values, and returns an SVG string prefixed with data:image/svg+xml;utf8,. Color the variance green or red based on sign — that gives the card its “smart” feel.

Step 5 — Render it as an Image
Drop an Image visual on the report, drag the measure into the URL field, and in the model view set the measure’s Data category to Image URL. Done — click a slicer button and the card swaps.

That’s it. Five steps, no custom visual, fully native Power BI.

Try it yourself

I’ve put the full DAX measure, a README with the step-by-step, and a preview screenshot on GitHub. Clone it, paste the measure into your model, and you’re up:

👉 Resources

Want to actually land a data job?

If you’re learning Power BI because you want a job in data — read this next bit.

I built FirstDataJob.com for exactly that. It’s the resource I wish I’d had when I was breaking into the field:

• Resume reviews built for data roles — not generic templates. We look at how you frame your projects, your tools, and your impact metrics so recruiters actually call back.

• Curated job listings — analyst, BI developer, data engineer roles, filtered for actual entry- and mid-level openings (not the “entry-level, 5 years required” trap).

• Upskilling tracks — Power BI, SQL, Python, and DAX paths that map to what hiring managers test for, not what looks good on a course catalog.

If a clickable KPI card felt approachable, the rest of the journey can too. Start at FirstDataJob.com.

Subscribe — I help you learn new Data Concept every week!

There’s a better way — and it uses a visual most Power BI developers have never tried: the HTML Content visual.

This Article/Video will let you build this visual in 5 minutes:

What is the HTML Content visual?

It’s a free, Microsoft-certified custom visual on AppSource. Install it once. From that point forward, anything you can write in HTML + CSS — cards, badges, bar charts, narrative panels, animated backgrounds — you can render inside a Power BI report. The HTML comes from a single DAX measure that returns a string.

So you’re installing one custom visual, but you’re building unlimited designs with it. That’s the unlock.

What we’re building today

A dark, glassy KPI tile with:

• The current year’s sales as the hero number

• A green or red YoY % badge that flips based on growth

• An “overall achievement” bar with a white reference line at 100%

• A by-category bar chart where every bar is green if it beat last year, red if it didn’t

All of it is one DAX measure rendered through the HTML Content visual. No Python, no R, no embedded webpage — just DAX that returns HTML.

If you like such videos in your posts, then do let me know in the comments.

Also if you are looking for jobs in data profession, it will be great to check this website for free account https://firstdatajob.com

(This website is helping students to find data jobs that they were unable to find on LinkedIn)

Stay Analytical, Stay Curious!

- Atikant Jain (AJ)
📍Perth, Australia

Quick personal note.

Most data professionals I talk to are stuck in the same loop:

- Scroll LinkedIn for 2 hours

- Apply to 30 random listings

- Hear back from maybe 1

The job boards aren’t the problem — they show every job to everyone. There’s no filtering for what actually fits YOU.

So over the last 8 months, I built FirstDataJob to fix exactly that.

Here’s what it does:

1. You upload your CV + set your target role

2. We pull fresh data/analytics jobs from across India and Australia every day

3. We score each one against your skills and surface only the high-fit ones

You spend 5 minutes a week, not 5 hours.

Free plan: weekly digest of matched roles

Pro plan: daily digest + I personally review your resume + 1:1 30-min consulting call with me

If you’re job-hunting now or planning a switch in the next 6 months:

👉 https://firstdatajob.com

Reply to this email with thoughts. I read every one.

— Atikant Jain (AJ)

Founder, FirstDataJob

(Analytical Guy on YouTube)

Then I open my laptop, and 9 out of 10 analysts I work with - at startups, in Big 4, in finance teams - are living inside a spreadsheet. Cleaning data. Building reports. Sending dashboards to their boss before the 10 AM meeting.

Here’s the thing nobody wants to admit:

AI didn’t kill Excel. AI made Excel more important.

Because the moment you have AI generating data, summaries, reports, and forecasts - somebody still needs to check it, slice it, filter it, and present it. And for that last mile? Nothing beats a well-built Excel report.

The good news? You don’t need 6 months of YouTube tutorials. You need maybe 20 focused minutes to learn the modern Excel stack.

Let me show you exactly what I mean.

The 20-Minute Modern Excel Stack

Here’s what actually matters in 2026 — forget VLOOKUP-and-pivot tutorials from 2015:

1. Dynamic arrays — FILTER, UNIQUE, SORT, SEQUENCE. One formula, infinite rows.

2. Search-as-you-type filtering — give your spreadsheet a “Google-like” experience.

3. Cascading dropdowns — country → category → product, all driven by formulas.

4. One-click PDF export — branded headers, footers, page numbers, the works.

5. A reusable template that updates the second you change a single cell.

Sounds like a lot? It isn’t. I packed all of it into one video.

Watch: Build a Dynamic Excel Report from Scratch

In this video you’ll build:

• A clean filtered report driven by dropdowns

• A live search box that narrows rows as you type

• A polished one-click “Export to PDF” button with your branding

Open Excel side-by-side, hit play, and by the end you’ll have something you can actually show your boss tomorrow.

Download Files: Dataset + Template + VBA Script

“But I’m Already Using AI for This”

Cool — let me ask you three questions:

• Can you trust AI with the financial data you can’t paste into a chatbot? (Hint: confidentiality.)

• When your CEO asks for “the same report but only for Q2 India,” can AI hand it back in 4 seconds? (In Excel, you change one dropdown.)

• Can AI build something your finance team can keep using, without you, next month?

Excel + AI is the actual unlock. AI to think. Excel to deliver. The professionals who win in this era aren’t the ones picking sides — they’re the ones using both.

Want to Go Deeper? Here’s the Full Roadmap

If the dynamic reporting video clicked for you, these playlists are the next steps:

📊 Excel Foundations Playlist
Excel Formula Full Course: Become a PRO in 45 Minutes
Start here if you’re rebuilding your Excel basics for 2026.

⚡ Advanced Formulas & Dynamic Arrays
Complete Playlist for Beginner to Advanced

AI Enabled Playlist

Excel Formula Cheat sheet (Video follow along)

The Bottom Line

The world isn’t moving from Excel to AI. It’s moving toward professionals who can do both.

You’ve got 20 minutes. You’ve got the video. The only question is whether the next person who opens your spreadsheet thinks “this is a mess” — or “who built this?”

Hit play. Build it with me.

— Analytical Guy

📩 If this was useful, subscribe — I send one practical Excel + analytics breakdown every week.
🔗 Got a request? Reply to this email or comment below.

Your CEO asks a simple question:

“What’s our total revenue?”

Three people give three different answers.

• $10.5 million

• $9.8 million

• $11.2 million

Which one is correct?

This chaos happens because you don’t have a proper data model.
But there’s a solution: Star Schema.

In this post, I’ll break down exactly why Star Schema matters, how to build one in Power BI, and why it’s the foundation of every professional data warehouse.

If you would like to watch the video instead of reading, you can watch it here:

Why Star Schema Matters (The Real Problem)

Let me show you what happens without a star schema.

Your Data (All Mixed Together)

Orders Table (No Structure):

• order_id: 1001

• customer_name: “John Doe”

• customer_email: “john@email.com“

• product_name: “MacBook Pro”

• product_category: “Electronics”

• product_price: $1,999

• order_amount: $1,999

• order_date: 2024-01-15

The Problem

When a product category changes from “Electronics” to “Consumer Tech”, where do you update it?

• Orders table? (50,000 rows?)

• Excel reports? (5 different files?)

• Power BI & Tableau? (different logic?)

Nobody knows. Everything breaks.

The Impact

• ⏳ Slow updates

• 😱 Inconsistent reports

• 🔥 Data integrity issues

• 💸 Lost productivity

With Star Schema

One update. One place. Everything updates automatically.

What Is Star Schema? (The Solution)

Star Schema organizes data into two types of tables:

1. Fact Tables (Center of the Star)

Fact tables store measurable data — the numbers you analyze.

Example: fct_Sales

• sales_key

• customer_key

• product_key

• date_key

• order_amount

• units_sold

• discount

• tax

Rule: Only numbers + foreign keys. No descriptions.

2. Dimension Tables (Context Around the Star)

Dimension tables store descriptive attributes.

dim_Product

• product_key

• product_name

• category

• brand

• price

dim_Customer

• customer_key

• name

• email

• segment

• region

dim_Date

• date_key

• date

• month

• quarter

• year

How They Connect

• fct_Sales.customer_key → dim_Customer

• fct_Sales.product_key → dim_Product

• fct_Sales.date_key → dim_Date

This enables fast, consistent analysis.

Normalization vs Denormalization (The Confusion)

Normalization (Operational Systems)

Used in: Banking, transactions, apps

Pros:

• No redundancy

• Accurate updates

• Strong data integrity

Cons:

• Too many joins

• Slow for analytics

• Complex

Denormalization (Analytics Systems)

Used in: Power BI, Data Warehouses

Pros:

• Fast queries

• Simple structure

• Easy for business users

Cons:

• Redundancy

• Slower updates

The Truth

You need both:

• Operational DB → Normalized (fast writes)

• Data Warehouse → Star Schema (fast reads)

Star Schema vs Snowflake Schema

A snowflake schema is a variation of a star schema where dimension tables are further normalized into multiple related tables (e.g., product → category → subcategory), reducing redundancy but increasing the number of joins required for queries.

It is typically used when data storage optimization, strict data integrity, or complex hierarchical relationships are more important than query speed—common in large enterprise data warehouses with highly structured dimensions.

However, star schema is generally preferred because it keeps dimensions in a single table, resulting in fewer joins, faster query performance, simpler models, and better usability in tools like Power BI, making it ideal for analytics and business reporting.

Key Takeaways

1. Solves Multiple Truth Problem

One source = consistent numbers.

2. Fact Tables = Numbers

Revenue, units, profit.

3. Dimensions = Context

Customer, product, date.

4. Denormalization = Speed

Faster analytics queries.

5. You Need Both Worlds

OLTP (normalized) + DW (star schema).

6. Star > Snowflake for Power BI

Less joins = faster performance.

7. One Change, Everywhere Updates

Update once → reflect everywhere.

How to Implement in Power BI

Step 1: Create Fact Table

fct_Sales with keys + measures.

Step 2: Create Dimensions

dim_Customer, dim_Product, dim_Date.

Step 3: Build Relationships

• customer_key

• product_key

• date_key

Step 4: Create Measures

Revenue = SUM(fct_Sales[order_amount])
Profit = SUM(fct_Sales[profit_amount])
Units = SUM(fct_Sales[units_sold])

Step 5: Build Reports

Use dimensions for slicing/filtering.

Resources: Star Schema Code + ReadMe file

Questions?

• What’s your biggest challenge in data modeling?

• Are you using star schema already?

• Want a deeper dive on something specific?

Drop a comment — I read everything.

Subscribe for more practical guides on data analytics, AI tools, and building a high-value analyst career.

Stay analytical. Stay curious.

Atikant Jain
Your Analytical Guy
admin@analyticalguy.tech

I just completed something I thought would take an entire week in just one hour.

Here’s what happened: I connected a Power BI semantic model to Claude AI and ran a comprehensive audit. What I discovered was shocking. The model had critical data quality issues, performance bottlenecks, and organizational problems that would have taken me days to find manually.

The Starting Point

The “Customer Profitability Sample” model looked fine on the surface:

• 9 tables

• 47,646 fact rows

• 44 measures organized in display folders

• 8 relationships configured

But underneath, there were serious problems.

The Critical Issues I Found

Issue #1: 21 Orphaned Customer Keys

I ran a simple DAX query through Claude: “Find customer keys in the Fact table that don’t exist in the Customer dimension.”

Result: 21 keys were referencing non-existent customers. This meant 1,953 fact rows were broken—they weren’t properly linked to any customer. Any report filtering by customer would give incomplete results.

Traditional approach: Manually compare the two tables, identify missing keys, decide how to handle them. Maybe 3-4 hours of work.

Claude approach: Identify the problem, suggest the fix, execute it. 10 minutes.

Watch the Practical Video Guide Now:

Issue #2: Data Type Mismatches

I discovered that:

• Fact[Product Key] was String, but Product[Product Key] was Int64

• Customer[Industry ID] was String, but Industry[ID] was Int64

These type mismatches force SQL to convert data types on every join. That’s a 15-20% performance penalty on every Product filter. Hidden but costly.

Issue #3: Sparse Columns

Three columns had 99%+ zeros:

• Material Costs: 99.97% zeros (47,630 empty rows out of 47,646)

• Taxes: 99.96% zeros

• Subscription Revenue: 99.78% zeros

These were wasting storage space and cluttering the field picker with essentially unusable data.

How Claude AI Solved This

Instead of manually fixing each issue, I used Claude to:

1. Audit automatically - Identify all problems in one pass

2. Generate code - Create the fixes in TMDL (the semantic model language)

3. Execute changes - Apply fixes to the live model

4. Validate results - Verify 100% data integrity

The Fixes

Fix #1: Add Unknown Customers

I asked Claude to add 21 “Unknown Customer” records for the orphaned keys. This took 5 minutes. The 1,953 broken rows now properly link to customers.

Fix #2: Align Data Types

Changed Product Key from String to Int64. Changed Industry ID from String to Int64. Both now align with their dimension tables.

Impact: 15-20% faster queries on Product and Industry filters.

Fix #3: Delete Sparse Columns

Removed Material Costs, Taxes, and Subscription Revenue columns. Also deleted 3 measures that only summed zeros.

Impact: 300 KB storage saved, cleaner field picker, zero functional loss.

The Results

Before optimization:

• Data integrity: ~96% (21 orphaned keys)

• Type mismatches: 2 (performance penalty)

• Sparse columns: 3 (wasted space)

• Documentation: None

After optimization:

• Data integrity: 100% ✓

• Type consistency: 100% ✓

• Sparse data: Removed ✓

• Performance: +15-20% ✓

• Documentation: Complete ✓

The Time Comparison

Typical optimization work:

• Audit: 4-6 hours

• Data quality fixes: 3-4 hours

• Type corrections: 2-3 hours

• Documentation: 2-3 hours

• Total: 11-16 hours

With Claude AI:

• Audit: 15 minutes

• Fixes: 20 minutes

• Validation: 20 minutes

• Documentation: 5 minutes

• Total: 1 hour

That’s 14-15x faster.

What I Learned

AI isn’t replacing BI professionals. It’s eliminating the tedious parts so you can focus on strategy.

What Claude handled:

• Pattern recognition (finding orphaned keys)

• Code generation (TMDL edits)

• Validation (checking all relationships)

• Documentation (creating reference guides)

What I handled:

• Strategic decisions (which columns to delete)

• Quality judgment (validating findings)

• Final reviews (ensuring correctness)

The Best Part

Every change is version-controlled. The entire model is defined in TMDL (text-based), so I can see exactly what changed, when, and why. This is reproducible, auditable, and maintainable.

Resources Used:

Drive Link

If You Work With Power BI

Ask yourself:

• How many hours are you spending on manual audits?

• How many data quality issues are you missing?

• How long does it take to document your models?

• How often do you fix performance issues?

Claude AI can handle all of this. Not perfectly—it still needs human judgment—but fast enough to change how you work.

What’s Next

I’m building out this workflow into a full optimization framework. Next: implementing this for larger models (500K+ rows) and exploring how to automate ongoing monitoring.

If you want to try this yourself, here’s what you need:

1. Power BI Desktop (running locally)

2. Claude AI access (API or web interface)

3. Basic understanding of Power BI concepts

4. 2 hours of time

The ROI is immediate.

Questions? Drop them in the comments. I’ll be working on advanced DAX optimization next—what topics would you like to see?

Stay Updated

Subscribe for more practical guides on data analytics, AI tools, and building a high-value analyst career.

Stay analytical. Stay curious.

Atikant Jain
Your Analytical Guy
admin@analyticalguy.tech

A few years ago, “entry-level” meant one thing:

0 years of experience.

Today?

It looks more like this:

2000: SQL → get a job
2005: SQL + Excel → get a job
2010: SQL + Excel + Python → get a job
2015: SQL + Excel + Python + Stats → get a job
2020: SQL + Excel + Python + Stats + ML → get a job

2026:
SQL + Excel + Python + Stats + ML +
LLMs + MLOps + AI Agents + System Design + Cloud + Domain Expertise

• Communication + Business Thinking + Ownership

• 5 years of experience

→ Entry-level job

Let’s be honest.

The bar didn’t rise.

It multiplied.

And if you’re feeling overwhelmed right now—
you’re not behind…

You’re reacting to a system that changed faster than anyone prepared you for.

Here’s the uncomfortable truth

Most people are trying to learn everything.

• Every tool

• Every trend

• Every buzzword

And that’s exactly why they stay stuck.

Because the market doesn’t reward more skills.

It rewards clear positioning + proof of impact.

What actually works in 2026

After working with analysts and data professionals, I see the same pattern:

The ones who grow fast don’t chase everything.

They:

• Pick 1–2 core strengths

• Build visible proof (projects, dashboards, case studies)

• Learn just enough AI to amplify, not overwhelm

• Speak the language of business, not just tools

The gap no one is talking about

There’s a massive difference between:

“I know SQL, Python, Power BI…”

vs

“I can help a company increase revenue, reduce cost, or make better decisions.”

Most resumes sit in the first category.

Hiring happens in the second.

If you’re stuck, here’s the reality

You don’t need:

• 10 more courses

• Another certification

• A new roadmap every week

You need clarity + direction + feedback.

What I’m doing about it

I’ve started working 1:1 with a small number of people to help them:

• Cut through the noise

• Build a focused skill stack

• Create portfolio projects that actually stand out

• Position themselves for real opportunities

If that’s something you’ve been struggling with, you can book a session with me here:

👉 BOOK NOW

No fluff. No generic advice.

Just a clear plan based on where you are and where you want to go.

The market is harder than before.
But it’s also clearer than ever:

The winners aren’t the ones who know everything.
They’re the ones who know what matters.

Stay analytical. Stay curious.

Atikant Jain
Your Analytical Guy
admin@analyticalguy.tech

Modern data teams don’t fail because of lack of tools.
They fail because of poor data structure.

If your reports break unexpectedly, metrics don’t match across dashboards, or your Power BI model feels fragile—you don’t have a tooling problem.

You have an architecture problem.

The Medallion Architecture solves this.

The Core Idea

At its simplest, the Medallion Architecture is about layering your data so that each stage has a clear responsibility.

Instead of messy, tangled pipelines, you get a structured flow:

Each layer builds on the previous one.

No shortcuts. No mixing responsibilities.

Now if you want to skip reading and watch a 5 minutes YouTube video explaining this concept, then watch it here:

For others, lets continue reading :) :)

🥉 Bronze Layer — Raw, Untouched Data

This is your foundation layer.

Think of Bronze as a data lake landing zone where everything arrives exactly as it is.

What goes into Bronze:

• Raw extracts from databases

• CSV uploads

• API responses (JSON)

• Logs and event streams

Leave a comment to get complete PDF file and roadmap.

Leave a comment

Key Rules:

• No transformations

• Append-only (never delete/update)

• Full history preserved

• Include metadata (timestamp, source)

Why this matters

Bronze is your insurance policy.

If business logic changes tomorrow, you don’t panic.
You simply rebuild downstream layers.

Without Bronze, you’re stuck fixing broken reports instead of fixing the root cause.

🥈 Silver Layer — Where Data Becomes Reliable

This is the most important layer.
And the one most teams either skip—or get wrong.

Silver is where data is:

• Cleaned

• Validated

• Standardized

• Joined

Typical transformations:

Bronze.Customers
    ↓
[Remove nulls]
[Deduplicate]
[Standardize formats]
[Apply business rules]
    ↓
Silver.Customers

What happens here:

• Duplicate records removed

• Data types fixed (dates, currency)

• Business rules applied

• Tables joined into meaningful structures

• Data quality checks enforced

Key Principles:

• Deterministic → Same input = same output

• Reusable → Used by multiple reports

• Documented → Every transformation is explainable

• Centralized → Fix once, benefit everywhere

The Big Shift

Most beginners clean data in:

• Power Query

• DAX

• Excel

That’s a mistake.

All data cleaning belongs in Silver.

Because:

If you fix data in reports, you fix it 10 times.
If you fix it in Silver, you fix it once.

🥇 Gold Layer — Built for Speed & Business

Gold is where data becomes decision-ready.

This is your:

• Power BI semantic model

• Star schema

• Aggregated tables

Structure:

           ┌──────────────┐
           │  Dim_Date    │
           ├──────────────┤
           │  Dim_Product │
           ├──────────────┤
           │ Dim_Customer │
           └──────┬───────┘
                  ↓
           ┌──────────────┐
           │  Fact_Sales  │
           └──────────────┘

What happens here:

• Metrics are pre-calculated

• Data is aggregated

• Business terms replace technical fields

• Performance is optimized

Examples:

• Total Revenue

• Profit Margin

• Customer Segmentation

• Monthly Sales Summary

Why Gold exists

Because computing everything on-the-fly is slow.

Gold ensures:

• Fast dashboards

• Consistent metrics

• Self-service analytics

How It All Connects (End-to-End Flow)

Let’s say you have 3 data sources:

• POS system

• Online store

• Marketplace API

Your pipeline looks like this:

Why This Architecture Works

1. Separation of Concerns

Each layer does one job—and does it well.

2. Reusability

Silver becomes the single source of truth for all reports.

3. Scalability

You can add new data sources without breaking existing models.

4. Auditability

You can trace any number in a dashboard back to its origin.

5. Performance

Gold ensures reports are fast—even with large datasets.

Common Mistakes (Avoid These)

❌ Skipping Silver

Going directly from raw data to Power BI.

→ Leads to messy DAX, inconsistent metrics, and chaos.

❌ Transforming in Bronze

Trying to “optimize early.”

→ You lose the ability to rebuild logic later.

❌ Overloading Gold

Creating too many aggregated tables.

→ Storage explodes, refresh slows down.

❌ No Data Lineage

Not knowing where a number comes from.

→ Zero trust in data.

❌ Fixing Data in Reports

Using Power Query/DAX for cleaning.

→ Every report becomes its own pipeline.

Where This Fits

The Medallion Architecture is ideal if you:

• Work with multiple data sources

• Build Power BI dashboards

• Use Microsoft Fabric / Databricks / Snowflake

• Handle growing datasets

It may be overkill if:

• You have a single small dataset

• No transformation complexity

• No scaling requirement

Medallion vs Star Schema (Quick Clarity)

• Medallion Architecture → Organizes your pipeline

• Star Schema → Organizes your reporting layer

They are not competitors.

They work together.

What You Should Do Next

If you’re currently building dashboards:

1. Map your current pipeline

2. Identify missing layers

3. Start with Bronze (easy win)

4. Invest heavily in Silver

5. Keep Gold focused and lean

Final Thought

Most data problems are not technical.

They’re structural.

The Medallion Architecture gives you:

• Clarity

• Control

• Confidence

And once you implement it properly,
you’ll never go back to messy pipelines again.

Let’s Talk

What does your current setup look like?

• Direct from raw data?

• Partial layering?

• Fully structured pipeline?

Reply and let me know—I read every response.

Stay Updated

Subscribe for more practical guides on data analytics, AI tools, and building a high-value analyst career.

Stay analytical. Stay curious.

Atikant Jain
Your Analytical Guy
admin@analyticalguy.tech

Next: What are Semantic Model in Power BI and other Data Platforms.

Hey everyone,

I just dropped a new video that’s going to change how you think about Power BI security.

Here’s the problem I see all the time: security configuration in Power BI is tedious, repetitive, and easy to get wrong. You’re clicking through Tabular Editor, writing DAX expressions, managing TMDL files—it’s hours of work for what should be a 10-minute job.

So I built this guide to show you two paths:

Path 1: The Traditional Way (What you probably do now)

• Static Row-Level Security (RLS) setup

• Dynamic RLS configurations

• Object-Level Security (OLS) in Tabular Editor

• TMDL scripting for version control

You’ll learn the fundamentals, the best practices, and why these matter. This knowledge is essential.

Path 2: The Modern Way (What’s about to change your workflow)

• AI prompts that generate security rules in seconds

• Automatic configuration without manual clicking

• Same security, 1/10th the time

If you want complete roadmap and prompt documentation, then leave a comment:

Leave a comment

The video walks through both approaches side-by-side. You’ll understand why each step matters, when to use manual config, and when to let AI handle it.

Why This Matters Right Now

If you’re building enterprise reports or managing security across multiple datasets, this is a game-changer. I’m seeing teams cut their security setup time from 4+ hours down to 15 minutes—mostly by combining smart prompting with Tabular Editor workflows.

Plus, security governance is only getting more important. Whether you go the traditional route or the AI route, you need to know both. Your stakeholders will expect it.

What You’ll Get From the Video

✓ Complete RLS & OLS fundamentals – No gaps, no skipped steps
✓ Hands-on Tabular Editor workflows – Real demo, not theory
✓ TMDL scripting breakdown – Why it matters for teams
✓ AI automation in action – How to prompt for security configs
✓ Practical takeaways – What to use on your next project

Watch Now

One More Thing

If you’re not already subscribed to the YouTube channel, now’s a good time. I’m dropping deep-dive content on Power BI security, AI integration, and Claude every week. This is the stuff that levels you up from “knows Power BI” to “understands Power BI.”

Questions? Hit reply—I read every email.

Subscribe for more practical guides on data analytics, AI tools, and building a high-value analyst career.

Stay analytical. Stay curious.

Atikant Jain
Your Analytical Guy
admin@analyticalguy.tech

“AI will replace Power BI Developers.”

You’ve probably heard this everywhere lately.

So instead of debating it…

I decided to test it.

I tried building a real Power BI report using AI — the same kind of work we do daily.

No hype. No theory. Just actual results.

Here’s the interesting part:

Some things worked way better than expected.

Some things completely broke.

And one part surprised me the most —
it’s the exact place where most developers think they’re safe.

So… can AI actually replace us?

I won’t spoil it here.

But I’ve broken it down into a simple framework you can use to understand:

• What AI can already do today

• Where it still fails

• And what this means for your future as a developer

🎥 Watch the full video here

If you’re working with Power BI (or planning to),
this is something you should definitely understand right now.

Let me know what you think after watching — I read every reply.

Subscribe for more practical guides on data analytics, AI tools, and building a high-value analyst career.

Stay analytical. Stay curious.

Atikant Jain
Your Analytical Guy
admin@analyticalguy.tech

For years, building a Power BI report has followed a predictable (and manual) process:

• Gather requirements

• Load & clean data

• Build semantic model

• Create visuals

• Iterate with stakeholders

But what if this entire workflow could be automated?

Not partially… fully automated.

That’s exactly what Agentic AI enables.

What is Agentic AI in Power BI?

Agentic AI goes beyond simple prompts. Instead of just generating code, it:

• Understands your goal

• Breaks it into steps

• Executes each step independently

• Iterates until the final output is ready

Think of it as a self-operating Power BI developer

End-to-End Automation Architecture

In this section we will understand how Claude Code (Agentic AI) automates the full Power BI development process.

1. User / You (Blue Box)

   • You provide a brief description of your reporting requirements to Claude Code.

2. Claude Code (Orange Box)

   • Acts as the AI orchestrator.

   • It has various skills (slash commands) for Power BI tasks:

     • /powerbi-scaffold → sets up project structure

     • /powerbi-connect → connects to data sources

     • /powerbi-datamodelling → builds semantic model

     • /powerbi-reporting → generates visuals

     • /powerbi-beautify → cleans up formatting

     • /powerbi-pipeline → runs all above steps in sequence

   • Claude Code writes JSON + TMDL files to disk to create the PBIP project.

3. MCP Tool / Server (Green Box, Top Right)

   • Claude Code interacts with powerbi-modeling-mcp (MCP Server / Bridge) for orchestration.

   • Handles Analysis Services calls needed for semantic models.

4. Power BI Desktop (Yellow Box)

   • Runs locally to hold the live semantic model in memory.

   • Receives data and model structure from MCP / Claude Code.

5. PBIP Project on Disk (Purple Box)

   • Claude Code writes all files here:

     • .pbip project file

     • Report/pages/*.json → visuals/pages

     • SemanticModel/definition/tables/*.tmdl → tables & expressions

   • This project can then be opened in Power BI Desktop.

6. Final Output (Green Box, Bottom Right)

   • Open the .pbip in Power BI Desktop → final report ready.

⚠️ Does This Replace Power BI Developers?

Not exactly—but it redefines the role.

The focus shifts from:

Building reports → Designing intelligent systems & validating outputs

🎥 Watch the Full Demo

I tested this end-to-end using Claude Code to generate a complete Power BI report without even opening Power BI manually.

👉 Watch the full video here:

Subscribe for more practical guides on data analytics, AI tools, and building a high-value analyst career.

Stay analytical. Stay curious.

Atikant Jain
Your Analytical Guy
admin@analyticalguy.tech