DEV Community: Amailuk Joseph

The GitHub Portfolio That Gets You Hired (And Not For The Reasons You Think)

Amailuk Joseph — Sun, 26 Apr 2026 02:23:46 +0000

1. The Brutal Truth About Data Portfolios

Most GitHub data project portfolios fail. Not because the work is bad. Not because the SQL is wrong or the visualizations are ugly.

They fail because they're irrelevant — and hiring managers can smell irrelevance in about four seconds.

Here's what's sitting in your GitHub right now. Be honest.

SQL Project 1.
SQL Project 2.
SQL Project 3.

Does this look familiar?

That portfolio isn't going to get a second glance. It's getting a quiet tab-close and a mental note: newbie. Because that's exactly what it screams — someone who learned the tools but hasn't figured out why the tools exist.

Hiring managers aren't running a code school. They're running a business. A department with targets, pressure from above, decisions that need to happen fast and land right.

They're not sitting there thinking, "I wonder if this person knows how to write a LEFT JOIN."

They're thinking: Can this person really think? Can they find the thing that matters in a pile of noise? Will they make my team smarter — or just busier?

Your portfolio is supposed to answer those questions.

Right now, for most people, it doesn't even try.

That's what we're here to fix today.

2. Stop Building Projects. Start Solving Problems.

Here's a mental model most people carry into their first — or fifth — portfolio. It goes something like this:

"If I just get good enough at SQL, the dashboards will speak for themselves."

They don't.

You polish the queries. You make the charts clean. You pick the right color palette. And then you upload it to GitHub with a README that says:

"this project analyzes sales data using SQL and Python"
— and wonder why nobody's calling back.

Here's the painful truth. That project answered a question nobody in hiring for.

That is like being in an exam and find a question too difficult to answer. Your solution is to refine the question and then give it an answer.

Even if you give it the right response, that gets you nowhere.

The old thinking sounds like: "Let me show I can use the tools."

It is practiced in tutorials, rewarded in bootcamps, BUT... completely invisible in hiring rooms. Because tools are a given. Every other candidate has them too. They are just a means to an end

The shift is this — and it changes everything once it clicks.

Guaranteed.

Your portfolio isn't a collection of work.
It is a simulation of how you think on the job.

A hiring manager looking at your GitHub isn't asking what did you build today? They're asking how does this person move from raw data to a decision that matter?

They want to see the thinking process — the business instinct — not just the mere output.

New thinking IS different. It asks:

What problem is the business actually bleeding from?

It asks:

What decision is stuck because nobody looked at the data right?

It asks:

What changes with the existence of this analysis that wouldn't change before it comes to bear?

That is the reframe.

From practitioner to partner.
From someone who runs queries to someone who shapes strategy.

Your skillset isn't just a technical asset — it is a competitive lever. And your portfolio is where you prove you know the difference.

3. All Project Portfolio Fall In Two Categories

The fact is, not all Project Portfolio are equal. They are not even playing the same field. Most people only know of one kind.

The first kind: Learning Projects.

These are the ones built in or as a result of tutorials. The kind that follow a YouTube walkthrough or a Udacity or Udemy course.

Sales data are clean.
A dashboard recreated.
A SQL query optimized for practice.

Don't get me wrong. They are a vital part of the ecosystem — nobody skips this stage. The point here is that you are invisible to hiring managers.

IF that's the path you follow.

And here is why. Companies are generally not looking for someone to train. They have a business to run, a team already stretched thin, targets that wont wait for onboarding to get attended to.

Bringing in someone who requires hand-holding is not a hire — it is a constraint. A drag on the collective.

They get passed, and move to the next profile. Learning projects build skills. Full stop.

The second kind: Showing Projects.

These are different a different breed in every way that matters.

They do not start with a tool. They start with a problem — a real one, that business can relate with. The kind businesses actually loses sleep over.

They follow the thinking all the way through: here is what the data said, this is what it meant, and now the decision it unlocked.

Projects that show, are business-focused.
Insight-driven.
They add value, bringing something to the room.

They make a hiring manager lean forward and think — this person would make my team sharper!

That is the difference between someone who analyzes data and one who changes what a business does next.

Learning projects build skills. Showing projects get you hired.

Most portfolios are full of the first kind. You know, the ones that scream I am learning!

No offence to those learning.
BUT... the ones that stand out, are built almost entirely from the second.

The kind that SHOW.

4. Why Most GitHub Portfolios Fail (And You Will Wince Reading This)

This is going to sting a little. Stay with it.

Open your GitHub right now. Look at your repository names.

If any of the following are sitting there, you already know something is wrong — even if you could not name it until now.

"SQL Project."

"Data Analysis."

"Python Practice."

"Excel Dashboard."

A hiring manager opens your profile for the first time. It takes seconds. Maybe six if something catches the eye.

Those titles even though catchy, mean nothing.

All they communicate is: this person learned a tool.
What they miss to tell is: this person can help us.

That is the first and major failure. But it is not the only one.

The README That Reads Like a Technical Manual

You spent three paragraphs explaining your tech stack. Which libraries you used. How you cleaned the null values. How the schema is structured.

Sorry. Nobody asked.

A hiring manager is not debugging your code. They are evaluating your mind, in the context of skill and strategy.

A README that opens with "This project uses Python, Pandas, Matplotlib and SQLite to analyze..." has already lost the room.

The very first line told them what you used not what you found, not what changed —— or could change as a result of your input. Not what the business should or could do differently because this analysis exists.

See the difference?

Outputs Without Insight

A real business world buzzkill for any hiring manager worth their keep.

Here is a chart of monthly revenue.
Here is a customer segmentation by region.
Here is a product return rates over time.

And then — nothing.

No so what...
No this matters because...
No here is what the business is missing and here is what the data revealed.

Showing someone a chart is not analysis. It sums up as decoration. The insight is the work. The chart is just for show, how you present it.

Telling the Obvious

"Sales increased in December."

Yes. Everyone who has ever sold anything knows sales increase in December. It is almost a given

That is not an insight — that is a calendar observation.

Stating the obvious does not only fail to impress;

it actively signals that the person does not yet

know the difference between data and meaning.

Hiring managers notice this immediately. And they move on.

Scattered Tools, No Depth

SQL. Python. Tableau. Power BI. R. Excel. Spark. Airflow. Name it.

One project each.

This is not a demonstration of range. It is a demonstration of dabbling. It tells a hiring manager: this person has touched everything and mastered nothing.

Depth is what signals readiness. One tool used brilliantly across a real problem is way worth more than ten tools used shallowly across ten forgettable ones!

Now See the Difference

Here is what failure looks like — and what it looks like when the reframe happens:

❌ Weak Framing	✅ Strong Framing
"SQL Project — Customer Data"	"Why 30% of Customers Never Return: A Retention Analysis"
"Excel Sales Dashboard"	"Uncovering the Revenue Leak: Where the Sales Team Was Losing Deals"
"Python Data Cleaning Exercise"	"Fixing the Data That Was Costing the Finance Team 6 Hours Every Week"
"Tableau Visualization — HR Data"	"The Attrition Pattern Nobody Saw Coming: An HR Analytics Story"
"E-commerce Analysis"	"Which Products Look Profitable But Are Quietly Killing the Margin"

Same work.

Completely different signal.

One says: I practiced.

The other says: I think like someone who understands what is at stake.

5. The Blueprint: What a Hire-Worthy Project Actually Looks Like

5.1 Start With a Real Business Scenario

Here is where everything changes.

Not with a dataset. Not with a tool. Not with a technique you want to practice or have practiced.

It starts with a scenario — a real, breathing, pressure-filled business situation that someone, somewhere, is actually losing sleep over.

This is the move most people skip or are just plain ignorant about.

And it is the move that separates portfolios that get read from the ones that get closed.

You are not doing an exercise. You are stepping inside a company. That in the least, should be the mindset you have setting up the portfolios.

Does it sound like this:

You are a data analyst at a subscription-based SaaS company. Churn has ticked up three months in a row. The Head of Product thinks it is a UX problem. The VP of Sales thinks it is a pricing problem. Nobody has looked at the data hard enough to know who is right (or not), and the next board meeting is in six weeks.

Feel the difference?

That is not a project description. That is a situation with real and very high stakes. There is tension in it. There are people disagreeing. A deadline is looming and a consequence. There is something the business needs to know — and does not, at least not yet.

Now your analysis has a reason to exist. And bloom!

This is what "imagine yourself to be inside a company" actually means, or even feels like. Not fabricating data or inventing results.

It means grounding your work in a scenario that mirrors how real decisions get made — under pressure, with incomplete information, and with people waiting on the answer.

Your output, actually, virtually everything, mpore so your outlook changes automatically by virtue of the setting you have imagined into-place!

The dataset can be public. The scenario can be constructed as the foundation to your analysis. Yo do not need to re-write the play out, the script is for your mental processes.

What cannot be faked is the thinking — the ability to look at a business situation and know which questions actually matter.

When a hiring manager reads your project and feels the scenario, they stop evaluating your technical skills. They start imagining you on their team.

And that, my friend, is exactly where you want them.😁🫡

5.2 Define Real Questions

Before a single line of code.
Before the dataset is even open.
Before the tool is chosen.

The question comes first.

This is the discipline that separates analysts who get hired from analysts who get overlooked. Because anyone can run a query. Anyone can build a pivot table.

The person who walks in knowing which question(s) actually matters — that person is rare. And hiring managers feel that rarity immediately.

Real questions do not sound like:
> "What does the data show?"

That is not a question.
It is but a shrug dressed up as curiosity.

Real questions have teeth. They come from a business that is bleeding somewhere, growing somewhere, confused about something that costs money every single day the answer stays hidden.

They sound like this:

  > What is actually driving our revenue 
  > and is it the thing we think it is?

Where exactly are we losing customers — and at what point in the journey does it happen?

Which customer segment looks healthy on the surface but is quietly eroding underneath?

Are we discounting in ways that kill margin without winning loyalty?

What does our best customer look like — and are we acquiring more of them or fewer?

These questions do not come from a dataset.

They come from understanding that behind every dataset is a business with a problem it needs solved... a team that needs direction, and a decision that cannot wait forever.

The question shapes everything that follows.

Determines which data matters and which is noise. It determines what the analysis needs to prove or disprove.

Whether the final output is just a chart — or a recommendation that changes what the business does come Monday morning.

Tools do not drive analysis.

Questions do.

Choose the wrong question and even the most perfected SQL syntax ends up with nothing useful.

Tag the right question, well then a simple aggregation can unlock something the business has been missing for months.

Start there.

Always start from there.

5.3 Choose Business Metrics That Actually Matter

Numbers are everywhere in a business. Most of them are noise.

The analyst who pulls every available metric and presents a wall of numbers has not done analysis — they have done a data dump.

It looks thorough.
And actually exhausting to read aside from impossible to act on.

A hiring manager sees that and thinks:

This person does not have a clue as to what really matters. And you are done for...

The analyst who walks in with three metrics AND, can defend every single one — that person commands the room.

So which metrics do you choose?

Choose the ones tied to decisions.
The ones where a shift in the number changes what the business does next!

Not vanity metrics that look good in a presentation. Not activity metrics that measure busyness
(pun intended).

Metrics are not just measurements. They are a signal.
The one(s) you choose _tell a hiring manager everything about you.

Your understand of how a business actually operates_ — or whether you are still thinking like someone who just completed a course.

Choose revenue and you are saying: I understand what keeps the lights on.
Choose customer segmentation and you are saying: I know that not all growth is equal.
Choose retention and you are saying: I can see the leak before the bucket empties.

That awareness — the instinct to reach for the right number, and not just any number — is exactly what separates a data practitioner from a business thinker.

  > And business thinkers are the ones that get hired.

You are looking to analyse a business, what did you expect? How can you expect to analyse the thing you have not the slightest hint of?

And even before you ask, YES. If need be get a business certificate to better understand that world and its ecosystem.

So, in a nutshell, pick metrics that measure outcomes — the health, the growth, the risk underneath the surface.

In most business contexts, these three categories carry major weight.

Revenue.

Not just total revenue.
Revenue broken apart.
Where is it coming from — which products, which segments, which channels?

Where is it growing and where is it quietly shrinking?

Is the growth sustainable or it is propped up by a single customer, a single campaign, a single quarter, single purchase, or single quarter that may not repeat?

Revenue is never just a number. It is a story with layers — and the analyst who can unravel those layers is indispensable.

Customer Segments.

Not all customers are equal.
Some cost more to acquire than they will ever return. Others may be small but renew every year without friction and refer three more.

Segmentation is the work of knowing the difference in breaking the customer base into different groups that behave differently but share charateristics.

And appreciate the different things, and needs they respond to in making decisions.

When you can tell a business which customers to protect, which to develop, and which are quietly costing more than they are worth — that is insight that drives strategy.

Retention.

This is where most businesses bleed without realizing it. Or knowing why. Acquisition gets the attention, the budget, the celebration.

Retention settles for the spreadsheet no one opens. But the math is brutal and simple — keeping a customer is almost always cheaper than finding a new one.

Churn, cohort survival, time-to-second-purchase, engagement drop-off — these metrics tell the story of whether the business is building something durable or filling a leaky bucket and labelling it growth.

Choose metrics that connect to the question(s) you defined in section 5.2. Choose from what the business can actually act on.

And for every metric you include, be ready to answer one question a hiring manager will always be thinking but may never say out loud:

So what do we do with this?

Simply.
If the metric cannot answer that — drop it.

5.4 Use SQL to Investigate

SQL is not the point.

That feels uncomfortable to say in a data article. But it needs saying — because too many portfolios treat SQL like the destination when it is actually the vehicle.

  > The means, not the benefit. The processing tool,
  > not the proof of value!

When you write a query, you are not demonstrating technical skill. You are thinking out loud. You are asking the data a question and following where it leads.

Aggregating to see what the totals reveal. Segmenting to see where performance diverges.

Filtering to isolate the anomaly that the summary number was hiding.

SQL is how your thinking processing moves through data.

A hiring manager does not want to see elegant syntax. They' need to appreciate that your queries have a purpose — that each one is chasing an answer to something that matters.

Investigate with SQL. Let it do the heavy lifting underneath. But never mistake the tool for the work.

The work is the thinking. SQL just executes it.

5.5 Use Excel to Communicate

Once SQL has done the investigating, enter Excel — and its job is completely different.

In this context, Excel is not for analysis. It is for communication. As the layer where raw findings become something a Head of Sales, a VP of Operations, or a CFO can sit with over coffee and immediately understand.

Pivot tables that reorganize complexity into clarity. Charts that make a trend undeniable at a glance. A simple dashboard that puts the most important numbers in one place so nobody has to dig.

Simplicity is the skill here. Not sophistication.

The temptation is to make Excel impressive — dense formulas, layered tabs, conditional formatting stacked three deep. Resist it.

The person reading your output is busy, under pressure, and not interested in your spreadsheet architecture. They want to understand something faster because you built this.

Make it easy to read. Actually, let me put it differently.

Make it impossible to misread. That is the storytelling layer — and storytelling, done well, is what moves a business from data to decision.

5.6 Extract Insights — This Is the Differentiator

Everything up to this point has been preparation. This is the work.

Data is not insight.

This distinction sounds simple and gets ignored constantly. * A chart is not an insight.

A trend line is not an insight.
A table of numbers, however clean and beautifully formatted, is NOT insight.

Insight is interpretation plus implication. It is not what happened —

it is why it happened and what it means for what happens next.

Feel the distance between these two following:

"Sales dropped in Q3."

Everyone in the room can see that. The chart already told them. Stating it adds nothing — it just confirms you can read a graph.

Now this:

*"Sales dropped in Q3 due to a significant decline in enterprise client renewals — a segment that historically accounts for 60% of annual contract value.

Early indicators suggest the drop correlates with a competitor pricing shift in July and a lag in our own renewal outreach process."*

That is a different conversation entirely. You have named the problem. You have traced the reasoning. You have pointed toward the cause — and now the business knows where to look, what to fix, and which decisions cannot wait.

And then — the recommendations section. This is where most analysts stop short.

They surface the finding and hand it over. The analysts who stand out take one more step: they suggest a possible path forward.

Not to overstep, not to pretend they have all the answers — but to demonstrate that their mind does not stop at observation. It moves toward action.

That is the differentiator.
Not the SQL.
Not the dashboard.

The moment where you show a hiring manager that you do not just find what is wrong — you think about what to do about it.

5.7 Choose Business Metrics That Actually Matter

Numbers are everywhere in a business. Most of them are noise.

Pulling every available metric and presenting a wall of numbers is not analysis — it is data dumping. It looks thorough. It is actually exhausting to read and impossible to act on.

The analyst who walks in with three metrics and can defend every single one — that person commands the room.

Metrics are not just measurements. They are a signal. The ones you choose tell a hiring manager everything about whether you understand how a business actually operates — or whether you are still thinking like someone who just finished a course.

Choose revenue and you are saying: I understand what keeps the lights on.

Choose customer segmentation and you are saying: I know that not all growth is equal.

Choose retention and you are saying: I can see the leak before the bucket empties.

That awareness — the instinct to reach for the right number, not just any number — is exactly what separates a data practitioner from a business thinker.

And business thinkers are the ones who get hired.

5.8 Make Recommendations

This is where most analysts stop. Right at the edge of the most valuable thing they could offer.

They surface the insight. They hand it over. And then they wait.

The analysts who get hired do not wait. They take one more step — and that step is the one that signals readiness more than anything else in the portfolio.

Recommendations are not about being right. They are about being useful.

Nobody expects a candidate to walk in with a perfect three-year strategy built from a public dataset and a weekend of analysis.

That is not the bar. The bar is simpler and more human than that: can this person take what the data is saying and point us in a direction we can actually move toward?

That is it. Point them somewhere real.

And when you do, make it approachable.
A recommendation that sounds like "overhaul the entire enterprise sales motion" is not actionable — it is overwhelming.

It lands in a room and nobody knows who owns it or where it starts.

Break it down. Make it bite-sized.

Give the business something they can pick up Monday morning and begin.

It sounds like this:

"Pull a full list of enterprise clients whose contracts are due for renewal in the next 90 days. Cross-reference with engagement data — logins, feature usage, support tickets. Prioritize outreach to the ones showing low engagement. That is where the next wave of churn is most likely sitting."

Specific. Scoped. Scalable.

Something a team can act on without needing a consultant to translate it.

Or even simpler — offer a direction, not a destination:

*"The data points toward a retention problem, not an acquisition problem.

Before increasing the marketing budget, it may be worth understanding why existing customers are leaving first."*

One sentence. But it reframes the entire conversation. It tells the business where to look before they spend another dollar in the wrong direction.

This is useful. It is helpful.

That is the thing that makes a hiring manager look up from your portfolio and think — this person would make us sharper.

You are not expected to have all the answers. You are expected to care enough to offer the ones you can see.

That is more than enough to stand out.

6. The README That Gets You Noticed

Most people treat the README like an afterthought. The project is done, the code is uploaded, and then — almost as a formality — they type out a few lines explaining what tools they used and what steps they followed.

And just like that, the best part of the work becomes invisible.

The README is not documentation. It is your [sales] pitch.

It is the first thing a hiring manager reads. In many cases, it is the only thing they read. It is your one chance to pull someone into your thinking before they decide whether your project is worth their next five minutes — or whether they close the tab and move on.

Most people waste it.

What Most People Do

The typical README looks something like a paragraph about the dataset.

A list of steps: data cleaning, exploratory analysis, visualization.

A code block showing the SQL query. Maybe a screenshot of the dashboard at the end.

It reads like a lab report.
Thorough, technically honest, and completely devoid of anything a business person would care about.

Nobody in a hiring room is asking how you cleaned the nulls. They are asking what you found — and what it means.

What a Noticed README Actually Looks Like

Structure it like a business document, not a technical walkthrough. Every section should earn its place by answering something a decision-maker actually needs to know.

Business Context. Open here.
Not with the dataset — with the situation.

What company are you inside?
What problem are they facing?
What is at stake if nobody looks at this data carefully?

Make the hiring manager feel the scenario before they see a single number.

Two to three sentences done well here changes everything that follows.

Key Questions. What were you trying to find out?
List the questions that drove the analysis — not the technical tasks, the business questions.

Where are customers dropping off?
Which segment is most profitable?
What is driving the churn?

Questions signal that the work had direction and purpose, not just an activity.

Insights. This is the heart of the README and it deserves the most care. Do not bury findings in paragraphs. Surface them clearly.

Lead with the most important thing the data revealed. Explain not just what happened but why it matters. This is where weak portfolios hand over a chart and strong portfolios hand over a conclusion.

Recommendations. What should the business consider doing next? Keep it practical. Keep it scoped.

Even one well-reasoned recommendation tells a hiring manager that your mind moves from observation to action — and that is exactly the mind they are trying to hire.

Tools Used. Yes, list them — but save them for last. Tools are the how, not the what.

They belong at the bottom, not the headline. Leading with tools signals that you think the tools are the impressive part.

They are not.

The thinking is.

One README structured this way does more for a job search than ten projects documented like instruction manuals.

Because a hiring manager reading it does not feel like they are reviewing a submission. They feel like they are sitting across from someone who already understands the job.

That is the pitch. Make it count.

7. Why SQL + Excel Is a Power Combo (And Not Basic)

Let us address the voice in your head first.

The one that says you need Python.

That SQL and Excel are entry-level.

That without machine learning models and automated pipelines and a Jupyter notebook full of Pandas code, your portfolio will not be taken seriously.

That voice is wrong. Practically selling you air. It costs people opportunities every single day and counting.

Here is what is actually happening inside most companies — not the startups featured in tech blogs, not the FAANG engineering teams, but the businesses that are hiring right now, the ones with real budgets and real problems and real analysts on their teams doing real work.

They are living in SQL and Excel.

Not because they are behind. Because those tools work. Because a well-structured SQL query that answers the right business question in four minutes is worth infinitely more than a Python script that answers the wrong one in four seconds.

A clean Excel dashboard that a CFO can read without a tutorial is more powerful than a beautiful Plotly visualization that requires someone to explain the legend.

SQL and Excel dominate business analytics. They dominate operations. They dominate finance. They dominate the day-to-day rhythm of how decisions actually get made in companies that are not Google.

The people who dismiss this are usually the ones still building portfolios nobody is reading.

Depth beats tool stacking. Every time.

There is a particular kind of portfolio that tries to impress through volume. SQL, Python, R, Tableau, Power BI, Spark — one project each, spread thin across every tool the person has touched.

It looks broad.
Thou it signals nothing.

Because breadth without depth is just a list of things you have tried.

A hiring manager looking at SQL and Excel used masterfully — queries that peel back layers of a business problem, pivot tables that make a complex segmentation immediately readable, a dashboard that puts the right metric in front of the right person...

That hiring manager is not thinking "they should have used Python."

They are thinking: this person knows what they are doing.

Mastery is the signal.

Not the tool count.

SQL gives you access to the data — all of it, structured and queryable, pulled exactly the way the question demands.

Excel gives you the communication layer — the place where findings become decisions, where numbers become narratives that a non-technical stakeholder can sit with and act on.

Together, they cover the full distance from raw data to boardroom clarity.

That is not basic. That is the job.

Own it completely, demonstrate it deeply, and let the people chasing tool stacks keep wondering why they are not getting callbacks.

8. Example Project: Sales Performance & Customer Segmentation Analysis

Everything covered so far — the reframing, the blueprint, the README, the metrics — this is where it becomes concrete.

Real.

Something you can hold up and say: this is what it looks like when it all comes together.

Walk through this as if you are the analyst inside the company. Feel the scenario before you touch the data.

The Scenario

You are a data analyst at a mid-sized B2B software company. The Head of Sales walks over on a Tuesday afternoon with a question that has been sitting in the back of her mind for two quarters:

"We grew revenue this year — but something feels off. I do not know if we are growing with the right customers."

That is your brief. Vague, pressure-filled, and exactly the kind of question that separates analysts who thrive from analysts who freeze.

You go to the data.

The Business Questions

Before opening a single table, you define what you are actually trying to find out:

Which customer segments are driving the most revenue — and which are quietly underperforming?
Are high-revenue customers also high-retention customers, or are we winning big contracts and losing them fast?
Where in the customer base is growth coming from — new acquisition or existing expansion?
Which segments deserve more investment and which are costing more than they return?

Four questions. Every query you write from this point forward is in service of one of those four.

The SQL Investigation

You start by aggregating revenue by customer segment across the last two fiscal years.

SELECT
    customer_segment,
    YEAR(order_date) AS fiscal_year,
    COUNT(DISTINCT customer_id) AS total_customers,
    SUM(revenue) AS total_revenue,
    ROUND(AVG(revenue), 2) AS avg_revenue_per_customer
FROM sales_data
WHERE order_date >= '2022-01-01'
GROUP BY customer_segment, YEAR(order_date)
ORDER BY fiscal_year, total_revenue DESC;

The results surface something immediately. Enterprise clients represent 28% of the customer base but generate 61% of total revenue. Small business clients are the largest segment by volume — but average revenue per customer has declined 18% year over year.

You dig deeper. You look at retention by segment.

SELECT
    customer_segment,
    COUNT(DISTINCT CASE WHEN fiscal_year = 2022 THEN customer_id END) AS customers_2022,
    COUNT(DISTINCT CASE WHEN fiscal_year = 2023 THEN customer_id END) AS customers_2023,
    ROUND(
        COUNT(DISTINCT CASE WHEN fiscal_year = 2023 THEN customer_id END) * 100.0 /
        NULLIF(COUNT(DISTINCT CASE WHEN fiscal_year = 2022 THEN customer_id END), 0), 1
    ) AS retention_rate_pct
FROM sales_data
GROUP BY customer_segment;

Enterprise retention: 84%.
Mid-market retention: 71%.
Small business retention: 49%.

Now the picture is clear. The company is growing — but it is growing in the segment that churns fastest, spends least, and costs the most to support at scale.

The Excel Output

You bring the findings into Excel and build a clean, single-page dashboard. Three sections only.

A revenue breakdown by segment across both fiscal years — a simple bar chart, side by side, showing the shift in where revenue is coming from.

A retention rate comparison — three numbers, clearly labeled, color-coded by health. Green for enterprise. Amber for mid-market. Red for small business.

A customer value matrix — a simple two-by-two. Revenue contribution on one axis, retention rate on the other. Enterprise sits in the top right. Small business sits in the bottom left.

No extra tabs. No nested formulas. No color gradients that require a legend to decode.

A CFO with thirty seconds and a coffee can read this and know exactly where to look.

The Insight

Here is where you do not state the obvious.

You do not write: "Enterprise clients generate more revenue than small business clients."

Everyone can see that. The chart already said it.

You write this:

"Revenue growth in 2023 was driven primarily by an increase in small business client acquisition — a segment with a 49% retention rate and declining average contract value.

Meanwhile, enterprise clients, who represent 61% of total revenue and retain at 84%, remained flat in headcount.

The business is investing its growth energy in its least durable segment while its most valuable segment sits underdeveloped."

That is the insight. It names what happened, explains why it matters, and points directly at the tension the Head of Sales felt but could not articulate on that Tuesday afternoon.

The Recommendation

You do not prescribe a company-wide overhaul. You offer something the team can pick up and begin.

"Before the next acquisition campaign, consider a targeted expansion play within the existing enterprise base.

Identify enterprise clients below median contract value and assign a dedicated touchpoint — a check-in call, a product review, a renewal conversation — in the next 60 days.

The highest-return growth opportunity is not new logos. It is the 61% of revenue already in the room that has not been asked to grow."

Specific.
Scoped.
Actionable on Monday morning.

That is one project. One business question, followed all the way through to a recommendation a leadership team can act on.

No Python. No machine learning. No elaborate tech stack.

Thinking through with SQL.
Communicating with Excel.
Insight that earn their place.
Recommendation that points somewhere real.

That is the portfolio project that makes a hiring manager lean in.

9. Turning Your Project Into a Weaponised Resume

The project is done.
The README is sharp.
The dashboard is clean.
The insight landed.

And then you write on your resume: "Used SQL and Excel to analyze sales data."

Everything you built. Everything you found. Everything that made a hiring manager lean in — compressed into a line that says absolutely nothing about any of it!

That over there, is where good work goes to die.

The Problem With Weak Resume Language

Weak resume lines describe activity.
They tell a hiring manager what tool you held, not what you did with it.

Not what changed because of it.
Not what the business now knows that it did not know before you sat down with that dataset.

"Used SQL and Excel."

Every other candidate wrote that too. It does not separate you — it dissolves you into the pile.

And the pile is where opportunities fizzle out.

The Transformation

Strong resume language does three things simultaneously. It grounds the work in scale — so the reader understands the weight of what you were working with.

It names the business outcome — so they understand what the work was actually for.

And it connects the output to a decision — so they can see the value, not just the activity.

Feel the distance between these:

❌ Weak	✅ Strong
"Used SQL and Excel"	"Analyzed 100K+ sales records to identify revenue concentration across customer segments; surfaced insights that informed Q3 retention strategy"
"Built a dashboard"	"Designed an executive-facing Excel dashboard translating complex segmentation data into a single-page decision support view for senior leadership"
"Did customer segmentation"	"Segmented 8,000+ customer accounts by revenue contribution and retention rate; identified underinvested enterprise tier responsible for 61% of total revenue"
"Analyzed sales performance"	"Investigated two-year sales trend to diagnose growth risk; found 49% churn rate in primary acquisition segment driving long-term revenue instability"
"Made recommendations"	"Delivered targeted expansion recommendation redirecting growth focus to existing enterprise base — highest-return opportunity identified in the analysis"

Same project.

Completely different signal.

One tells the hiring manager you used tools. The other tells them you changed something — or would have, if you had been in the room. And how you would have done that given access.

The Language That Does the Work

There are specific words and constructions that carry business weight. Reach for them deliberately.

Lead with scale when it exists:
"100K+ records,"
"8,000+ accounts,"
"two-year dataset"

Scale signals that the work was not trivial and the findings were not guesswork.

Name the business outcome, not the technical process:
"to identify,"
"to diagnose,"
"to inform,"
"to support"

outcomes are what a business buys.
Process is just how you got there.

Connect to a decision wherever possible:
"informed strategy,"
"supported leadership decision,"
"redirected growth focus"

Analysts who move businesses toward decisions are indispensable.

Frame everything in the language of the business, not the language of the tool.

The business could care less that you wrote a GROUP BY clause. It cares that you found where the revenue was leaking and pointed toward the fix.

One project. Written with this level of intention, it becomes three to four resume lines that each carry real weight.

Lines that a hiring manager reads and thinks; this person has already done the job. They just did it somewhere else.

That is the weapon.

Build it deliberately.

10. Why This Approach Wins in Interviews

Here is what most candidates experience in an interview.

The hiring manager opens with: "Walk me through one of your projects."

And the candidate walks them through the tools. The cleaning steps. The queries. The chart they built at the end.

A technical tour of a technical process — delivered to someone who was never interested in the technical process.

The room stays polite. The energy stays flat.
And the candidate walks out thinking it went well because nobody stopped them.

It did not go well.

What the Interviewer Is Actually Listening For

Every interview question about your portfolio is really asking one of three things.

What did you find?
Not what you did — what you found.
What did the data reveal that was not visible before you looked?

What was the thing that changed the picture?

Why does it matter? So the revenue dropped in Q3 — why should the business care? What is the downstream consequence if nobody addresses this? What is at stake?

What would you do next? Where should the business look from here? What decision does this analysis make possible? What would you tell the Head of Sales on your way out of the room?

Three questions. Every project built using the blueprint in this article answers all three — naturally, specifically, and with the kind of business fluency that makes interviewers put down their pen and actually listen.

The Conversation Shift

When you have done the work this way, the interview changes entirely.

You stop reciting steps. You start telling a story. A business was facing a problem. You went into the data and found something. You understood what it meant. You pointed toward what to do about it.

That is not a candidate describing a project. That is an analyst describing a contribution.

Feel the difference in how this lands:

"I used SQL to query the sales table and then built a pivot table in Excel and made some charts showing revenue by segment."

Versus:

"I was looking at a company where revenue was growing but something felt structurally off. When I segmented by customer type and layered in retention data, it became clear they were acquiring heavily in their least durable segment — 49% annual churn; while their enterprise base, which drove 61% of revenue, was sitting flat and underserved. The recommendation was to pause on acquisition spend and run a targeted expansion play within the existing enterprise tier first."

Same project. One sounds like a tool user finishing an assignment. The other sounds like an analyst who understood the business, found the fault line, and knew what to do about it.

One gets a polite follow-up email. The other gets an offer.

The Move From Tool User to Analyst

This is the transformation the entire article has been building toward.

A tool user knows how to run the query. An analyst knows which question the query needs to answer — and why that question matters to the people sitting across the table.

A tool user presents outputs.
An analyst delivers conclusions.

A tool user waits to be told what to look at. An analyst walks in already knowing where the interesting problems live.

That shift does not happen because you learned a new tool. It happens because you changed how you think about the work — from practitioner to partner, from executor to advisor, from someone who analyzes data to someone who changes what a business does next.

Your portfolio, built the right way, is the proof that the shift has already happened.

By the time you sit down in that interview room, you are not hoping they see your potential.

You are showing them your thinking. Shaped by real business questions, grounded in real metrics, connected to real decisions. It is the most powerful thing you can bring into that room.

That is what wins interviews.

Not the SQL.
Not the Excel.
Not the tools.

YOU!

11. The One Thing That Changes Everything

Most people on finishing reading this will go update their README. Add a business context paragraph. Rename a project. Clean up the structure a little.

  > That is not the one thing.

The one thing is deeper than formatting. It is a complete shift in how you see the work — and your role in it.

Hiring managers are not looking for people who can write queries.

They are looking for people who can think with data.

People who walk into a messy business situation, find the signal inside the noise, understand what it means, and point the organization toward a decision it could not make before.

That is the job. Everything else — the SQL, the Excel, the dashboard, the README — those are just the tools you carry to do it.

When you build your portfolio from that place, something changes. Not just in how it looks. Or how it reads. But in what it communicates without a single word about your technical skills.

It communicates that you understand what businesses actually need — and that you are ready to provide it.

That is the thing that makes a hiring manager stop scrolling.

Build the portfolio that proves it.

Bonus: 3 Project Ideas You Can Start Today (SQL + Excel Only)

You do not need a new dataset. You do not need Python. You do not need a week to plan.

You need a real business question and the willingness to follow it all the way through.

Project One — Customer Churn Analysis
Scenario: A subscription business has seen churn tick upward for three consecutive months. Nobody knows which customers are leaving or when in the journey they drop off. Your analysis segments the customer base, identifies the churn pattern by cohort, and surfaces the segment most at risk. Your recommendation targets the 90-day renewal window as the highest-leverage intervention point.

Project Two — Sales Territory Performance Review
Scenario: A regional sales team is hitting overall targets but the Head of Sales suspects performance is uneven across territories. Your analysis breaks down revenue, deal volume, and average contract value by territory. You identify one region outperforming on volume but underperforming on value — and recommend a pricing conversation, not a headcount change.

Project Three — Product Return Rate Investigation
Scenario: An e-commerce company is seeing margin pressure it cannot fully explain. Your analysis connects return rate data to product category, customer segment, and purchase channel. You find that one product category returned at three times the average rate — concentrated almost entirely in a single acquisition channel. Your recommendation is to audit the product listing and customer expectation-setting in that channel before pulling the product entirely.

Three projects. SQL to investigate. Excel to communicate. Insight to differentiate. Recommendation to close.

Start one this weekend.

Checklist: Before You Publish Your GitHub Project

Run every project through this before it goes live.

Does the repository name describe a business problem — not a tool or a topic?

Does the README open with business context — not a dataset description?

Have you defined the key questions that drove the analysis?

Are your insights clearly separated from your outputs — and do they explain why, not just what?

Have you included at least one practical recommendation?

Is your SQL organized and readable — with comments that explain the purpose of each query, not just the syntax?

Is your Excel output clean enough for a non-technical stakeholder to read without guidance?

Have you removed anything that exists only to show technical effort rather than business thinking?

If every answer is yes — publish it. If any answer is no to any aspect — that is exactly where to spend the next hour.

What You Would Fix in 90% of Beginner Portfolios

The problems are almost always the same. And they are almost always fixable in an afternoon.

The name. Generic, tool-focused, invisible. Fix it by naming the business problem, not the technique.

The README opening. It starts with the dataset or the tech stack. Fix it by starting with the scenario — the business situation, the pressure, the question nobody had answered yet.

The missing so what. The analysis surfaces a finding and stops. Fix it by asking one more question after every finding: what does this mean for the business? Write that answer down. That is your insight.

The absent recommendation. The project ends at the output. Fix it by adding one scoped, practical recommendation — even a single paragraph that points the business somewhere real.

The tool parade. Seven tools, seven shallow projects, no depth in any of them. Fix it by going deep on two projects rather than wide across ten. Mastery is the signal. Breadth without depth is just a list.

Fix these five things and the portfolio is already in the top 20% of everything a hiring manager will see this week.

A Final Word

This article was never really about SQL. It was never about Excel, or READMEs, or project naming conventions.

It was about a paradigm shift in identity.

From someone who learned the tools — to someone who thinks with them.

From someone who builds projects — to someone who solves problems.

From someone who hopes a hiring manager sees their potential — to someone who shows them their thinking and lets the thinking speak.

The portfolio is not the destination. It is the proof that the shift has already happened inside you.

Build it that way.

Everything else follows.

Found this useful? Share it with someone still naming their projects "SQL Project 1." They need this more than they know.

No Developer Required: How to Embed Any Power BI Report on Your Website in 7 Steps

Amailuk Joseph — Thu, 09 Apr 2026 07:20:45 +0000

A Comprehensive Guide to Publishing and Embedding Power BI Reports on the Web with IFrames

courtesy: https//blog.coupler.io/power-bi-dashboard-examples

I. Introduction — Why Your Data Deserves to Be Seen

Here is a situation you might know all too well.

You spent hours — maybe days — building a Power BI report. The charts are clean. The numbers are accurate. The story your data tells is genuinely valuable.

You click through it one more time, satisfied, maybe even a little proud.

Then you close your laptop.

And that report? It sits there. Locked inside a tool that only you can open.

Invisible to the people who need it most. Doing absolutely nothing for anyone.

That is not a data problem. That is a sharing problem. And it is far more common than most people admit.

You Are Not Alone in This

Maybe you have tried sharing it before. You exported it as a PDF — and lost all the interactivity. You emailed a screenshot — and someone immediately asked a question the image could not answer. You shared your screen on a video call — and the moment the call ended, the data disappeared with it.

None of those solutions actually work.

Not for live data. Not for people who need to explore it on their own terms, in their own time, from wherever they are.

There is a better way. And it is simpler than you think.

What This Guide Does

This guide solves the sharing problem — completely, practically, and without requiring a single line of code written from scratch.

By the time you finish reading and following along, you will have taken your Power BI report from sitting privately on your computer to living publicly on a webpage — fully interactive, always current, accessible to anyone with a browser.

Here is what makes it work in plain language.

Power BI is Microsoft's tool for turning raw data into visual reports. Charts, graphs, tables, dashboards — all built on top of your data, all updated automatically when that data changes. If you have already built a report, you know what it can do. If you are newer to it, this guide assumes close to zero experience and builds from there.

Power BI Service is the cloud version of that tool. Think of it the way you think of Google Docs versus Microsoft Word — one lives on your computer, the other lives online and can be accessed from anywhere. Publishing your report to Power BI Service is the bridge between your machine and the world.

An iFrame is simply a way to display one webpage inside another. Picture a window cut into a wall. Through that window, your visitors see your live, interactive Power BI report — right there on your website — without ever leaving your page. They can click filters. Explore the data. Zoom in on charts. All of it. No Power BI account required on their end.

Think of it like installing a live TV screen inside your website. Not a photograph of a report. Not a static image. A real, breathing, interactive data experience — embedded directly into your page.

Who This Guide Is Written For

It is written for the person who:

Has built a Power BI report and has no idea how to get it onto a website
Has heard the word "iFrame" and assumed it was too technical to bother with
Has tried to figure this out alone and hit a wall somewhere in the middle
Is completely new to all of this and needs someone to start from the very beginning

No coding background required. No developer on speed dial needed. If you can follow instructions and copy and paste text, you have every skill this process demands.

What You Will Be Able to Do by the End

This guide takes you through seven clear, logical steps. Each one builds on the last. Nothing is skipped. Nothing is assumed.

By the time you reach the final section, you will have:

✅ Published your Power BI report to the cloud
✅ Generated a live embed code inside Power BI Service
✅ Understood exactly what that code means and how to adjust it
✅ Placed a fully interactive report onto a real webpage
✅ Tested it the way an actual visitor would experience it
✅ Learned how to troubleshoot the most common problems
✅ Adopted best practices that separate a professional embed from an amateur one

From zero to confident. Step by step. No shortcuts or skipped processes. No steps glossed over.

Your data deserves to be seen. Let's make that happen.

II. The Big Picture — Understand the Journey Before You Click Anything

Before you touch a single button, let's take a step back. Understanding what you are about to do — and why each step exists — makes the whole process click into place.

Skipping this part is exactly why most beginners get confused halfway through.

So here is the full journey, plain and simple.

The Three-Stage Journey

Think of publishing and embedding a Power BI report like setting up a display at a trade show.

You build your exhibit at your workshop.
You transport it to the venue.
Then you set it up behind a glass display so visitors can see it without touching it directly.

That is exactly what happens here — just digitally.

Stage 1 — Build It: Power BI Desktop

This is your workshop.
Power BI Desktop is the application installed on your computer where you design and build your report. Your charts, your filters, your layout — all of it comes together here.

It lives on your machine until you decide to share it.

Stage 2 — Publish It: Power BI Service

This is the venue.
Power BI Service is Microsoft's cloud platform, accessible at app.powerbi.com. When you publish your report, you are uploading it from your computer to the cloud — where it becomes accessible from anywhere, on any device.

Stage 3 — Share It: Your Website via iFrame

This is the glass display case.
Once your report lives in the cloud, Power BI gives you a small snippet of code — an iFrame — that you paste into your website. That code punches a live window into your webpage, showing your report to anyone who visits.

Why the Order Matters

Each stage depends completely on the one before it.

You cannot publish what you have not built
Neither can you generate an embed code for something that is not in the cloud
Nor embed what does not have a code

Miss a step and things WILL break.

Follow the sequence and everything connects naturally.

This guide walks you through each stage in exactly the right order.

III. Before You Begin — What You Need

No surprises halfway through. Let's make sure you have everything in place before the first click.

This section is short. But it matters.

Your Pre-Flight Checklist

Think of this like checking your bags before a flight. A few minutes of preparation now saves a lot of frustration later.

✅ 1. A Completed Power BI Report File (.pbix)

This is the report you built in Power BI Desktop. It is saved as a .pbix file on your computer. It does not need to be perfect — but it needs to exist and open without errors before you publish it.

Don't have one yet? Open Power BI Desktop, connect to any data source, build a simple chart, and save it. That is enough to follow along.

✅ 2. A Microsoft Account

You need this to access Power BI Service. A free Microsoft account works to get started. However, keep this in mind:

Account Type	What You Can Do
Free	Build reports in Desktop, limited publishing
Pro	Full publishing, sharing, and embedding access
Premium	Advanced embedding, no per-user license needed for viewers

For this guide, a Pro account or a free trial of Pro is recommended. Microsoft offers a 60-day free trial — worth activating if you have not already.

✅ 3. Access to Power BI Service

Open a browser and navigate to app.powerbi.com. Sign in with your Microsoft account. If the page loads and you see a dashboard — you are in.

That is all you need to confirm.

✅ 4. A Webpage Where You Control the HTML

This is where your embedded report will ultimately live. It could be:

A WordPress site (most common)
A Wix or Squarespace page
A raw HTML file you manage yourself

The key requirement is simple — you need to be able to paste code into the page. If you can edit your webpage, you are ready.

✅ 5. The Ability to Copy and Paste

Seriously. That is the most technical skill this process requires. Everything else this guide walks you through step by step.

IV. Step 1 — Sign Into Power BI Service

You have your report file ready. Your Microsoft account is set up. Now it is time to step into the cloud side of Power BI — the place where your report goes from sitting on your computer to being accessible anywhere in the world.

That place is Power BI Service.

What Exactly Is Power BI Service?

Here is the simplest way to think about it.

Power BI Desktop is Microsoft Word — it lives on your computer and that is where you do the work.

Power BI Service is like OneDrive or Google Docs — it lives in the cloud, and that is where you store, share, and manage what you have built.

They are two separate tools that work together. You build in Desktop. Publish and share through Service. One without the other only gets you halfway.

How to Get There

Open any web browser — Chrome, Edge, Firefox, it does not matter. Type the following address into your address bar and press Enter:

https://app.powerbi.com

You will land on the Power BI Service sign-in page.

Signing In

Click Sign In and enter your Microsoft account credentials — the same email and password you use for any other Microsoft product. Office 365, Outlook, Teams — same login.

If you do not have an account a Microsoft account, create one from that point & login.

Once you are in, you will see the Power BI Service home screen. Take a breath.

Nothing here is as complicated as it looks.

A Quick Orientation — What You Are Looking At

You do not need to know every corner of this interface. For now, focus on three areas:

Area	What It Is
Left Sidebar	Your main navigation — Home, Recent, Workspaces, and more
My Workspace	Your personal space — private to you, like a personal folder
Shared Workspaces	Team spaces — for collaborating with others in your organization

For this guide, My Workspace is where your report will land when you publish.

It is the safest, simplest place to start.

My Workspace vs. Shared Workspaces — What Is the Difference?

Think of My Workspace as your personal desk drawer. Only you can see what is in it by default.

A Shared Workspace is more like a communal filing cabinet — teammates can access it too.

For beginners publishing their first report, My Workspace is the right starting point. You can always move things later.

V. Step 2 — Publish Your Report from Power BI Desktop

This is where the magic starts.

Your report has been living quietly on your computer.

In this step, you send it to the cloud — officially making it available in Power BI Service and setting the stage for everything that follows.

The process is straightforward. Let's walk through it together.

Open Your Report in Power BI Desktop

Start by launching Power BI Desktop on your computer. Open the .pbix file you prepared earlier — the report you want to publish.

Take a moment to scroll through it.
Make sure everything looks right.
Check that your visuals load, your data is current, and nothing appears broken.

Think of this as a final quality check before sending something to print. Once it is published, your audience could see it. Make sure it is ready.

Finding the Publish Button

Look at the top of your screen. You will see a horizontal menu bar called the ribbon. Click on the Home tab if it is not already selected.

Toward the right side of the ribbon, you will see a button labeled Publish with a small Power BI icon beside it. It is hard to miss.

Click it.

Choosing Your Destination Workspace

A dialog box will appear asking you one simple question — where do you want to publish this report?

You will see a list of available workspaces. For this guide, select My Workspace. It is your personal space in Power BI Service and the simplest destination for a first publish.

Advisably, name your "My Workspce" to easily identify or label your work.

If you are publishing for a team or organization, select the appropriate shared workspace instead. The rest of the steps remain exactly the same.

Click Select to confirm.

What Happens Next — Plain Language

Power BI Desktop will display a progress bar with the message

"Publishing to Power BI."

What is actually happening behind the scenes?

Your .pbix file — the report and its underlying data — is being uploaded from your computer to Microsoft's cloud servers.

It is essentially the same as uploading a file to Google Drive or Dropbox. Just with a fancier progress bar.

It usually takes between a few seconds and a couple of minutes depending on your file size and internet connection.

Confirming Success

When the upload completes, a success dialog appears. You will see:

✅ A green checkmark
✅ The message "Your report was successfully published"
✅ A clickable link that takes you directly to the report in Power BI Service

Click that link.

It will open your browser and take you straight to your freshly published report in Power BI Service.

You are going to need it in the very next step.

⚠️ Common Hiccup — Publish Button Grayed Out?

If the Publish button appears faded and unclickable, one of two things is likely happening:

Cause	Fix
You are not signed into Power BI Desktop	Click Sign In in the top right corner of Desktop and log in
Your account is Free tier with no workspace access	Activate a Pro trial at app.powerbi.com under account settings

Fix either of those and the Publish button will become active immediately.

VI. Step 3 — Find and Verify Your Report in Power BI Service

Your report is in the cloud now. But before you generate any embed code, you need to do one important thing — confirm that what was published is exactly what you intended.

This step takes two minutes. It saves a lot of embarrassment later.

Navigating to Your Workspace

If you clicked the link on the success screen from the previous step, you are already here.

If not, head to your browser and go to:

https://app.powerbi.com

On the left sidebar, look for My Workspace and click it. This is where everything you just published has landed.

What You Will See — Three Items, Not One

Here is something that surprises almost every first-time user.

When you publish a single .pbix file, Power BI Service does not just create one item. It creates three. They appear listed together in your workspace and each one plays a different role.

Think of it like submitting a book to a publisher. They receive the manuscript, create a printed copy, and produce a summary card for the catalogue. Three things — one source.

Here is what each item actually is:

Icon	Item Type	What It Does
📊	Dataset	The raw data engine powering your report — the numbers behind the visuals
📄	Report	The visual story built on top of that data — charts, graphs, and layouts
📌	Dashboard	A curated highlights page — pinned visuals selected manually

For embedding purposes, the item you care about right now is the Report. That is the one your audience will see.

Opening and Verifying the Report

Click on the Report item — the one with the report icon beside it. It will open in your browser, rendering your full report exactly as you built it in Desktop.

Now check the following before moving on:

✅ All visuals load completely — no blank tiles or error messages
✅ Charts and graphs display the correct data
✅ Any filters or slicers on the report are working
✅ The layout looks clean and nothing is cut off

Why This Verification Step Matters

"Don't embed something broken."
That is the golden rule of this entire process. Once your report is live on a website, anyone who visits that page will see exactly what is there — errors included. A blank visual or a broken chart reflects poorly and confuses your audience.

Catching problems here, inside Power BI Service, is the right time. Fixing things after embedding means repeating steps unnecessarily. A two minutes check can entirely prevent that happening.

A Note on the Browser Address Bar

While your report is open, glance at the address bar. You will see a long URL that looks something like this:

https://app.powerbi.com/groups/me/reports/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

That long string of letters and numbers is your report's unique ID in the cloud. You do not need to copy it manually — Power BI will handle that in the next step. But it is useful to know it exists and that your report now has a permanent address on the web.

VII. Step 4 — Generate the Embed Code

This is the step everything has been building toward. Your report is built.

It is published.

It is verified. Now you are going to ask Power BI to hand you the key that unlocks your report for the web — the embed code.

One menu. A few clicks. And you will have exactly what you need.

Introducing the Publish to Web Feature

Power BI has a built-in feature designed specifically for this moment. It is called Publish to Web and it does one job exceptionally well — it generates a piece of code that lets you display your live, interactive Power BI report on any webpage in the world.

No developer needed. No complex setup.

Just a code snippet you copy and paste.

How to Access It

Make sure your report is open in Power BI Service — the browser version at app.powerbi.com. You should be looking at your fully rendered report right now.

Follow these steps exactly:

Click File in the top menu bar of Power BI Service
Hover over Embed Report in the dropdown
Click Publish to Web (public) from the submenu that appears

Important — you are looking for "Publish to Web (public)" specifically. There are other embedding options in this menu designed for organizational use. Those require viewers to have a Power BI login. The public option does not — which is what makes it perfect for websites.

The Critical Fork — Public vs. Organizational Embedding

Before you go further, you need to understand this distinction. It is simple but important.

Embedding Type	Who Can View It	Login Required
Publish to Web (public)	Anyone on the internet	❌ No login needed
Embed for your organization	Only people in your organization	✅ Power BI login required

For a public-facing website — a blog, a portfolio, a business site — Publish to Web (public) is the correct choice. That is what this guide uses.

For internal company dashboards or sensitive reports, use organizational embedding instead and consult your IT administrator.

Microsoft's Warning Dialog — What It Means

When you click Publish to Web (public), Microsoft will show you a warning message before proceeding. Do not let it rattle you. It is simply reminding you of something important.

The warning says, in plain language: "This report will be visible to anyone on the internet. Do not use this for sensitive or confidential data."

That is good advice. Heed it. If your report contains personal information, financial records, or anything private — stop here and use organizational embedding instead.

If your report contains general, non-sensitive data — a sales overview, a public survey result, a portfolio project — you are safe to proceed.

Click Create Embed Code to continue.

The Two Outputs Power BI Gives You

A new screen appears confirming your embed code has been created. Power BI gives you two things here and it is worth understanding what each one is for.

Output 1 — The Shareable Link

https://app.powerbi.com/view?r=xxxxxxxxxxxxxxxxxxxxxxxx

This is a direct URL. You can send it to anyone and they can open your report in a browser tab. Useful for sharing via email or messaging. Not what we need for embedding.

Output 2 — The iFrame Embed Code

<iframe title="My Report" 
  width="800" height="600" 
  src="https://app.powerbi.com/view?r=xxxx" 
  frameborder="0" 
  allowFullScreen="true">
</iframe>

This is what you need. This is the code that places your report directly inside a webpage. Copy the entire block of code — from <iframe all the way to </iframe>. Every character matters.

How to Copy It

Besides the iFrame code box, you will see a Copy button or you can click inside the code box, select all the text with Ctrl+A (or Cmd+A on Mac), and copy it with Ctrl+C (or Cmd+C).

Paste it temporarily into a plain text editor — Notepad on Windows, TextEdit on Mac — just to keep it safe while you work through the next steps.

VIII. Step 5 — Understand the iFrame Code

You have the code. It is sitting in your text editor, a dense-looking line of HTML that might seem intimidating at first glance. But here is the truth — it is not complicated at all. Every part of it has a simple, logical job.

Taking two minutes to understand what you are looking at makes the next steps feel completely natural.

It also means that when something does not display quite right, you will know exactly which part to adjust.

The Picture Frame Analogy

Think of the iFrame tag like a physical picture frame. You choose the size of the frame. You choose where it hangs on the wall. And the image inside — your Power BI report — updates itself automatically without you ever touching the frame again.

The frame is just a container. The report inside it is live.

The Full iFrame Code — Laid Out Clearly

Here is what your embed code looks like. Every report will have slightly different values — particularly in the src address — but the structure is always the same.

<iframe 
  title="My Power BI Report"
  width="800" 
  height="600" 
  src="https://app.powerbi.com/view?r=xxxxxxxxxxxx" 
  frameborder="0" 
  allowFullScreen="true">
</iframe>

Now let's break every single piece of this down.

Plain-Language Breakdown

Code Attribute	What It Actually Means
`<iframe>`	Opens the display window — tells the webpage "a frame starts here"
`title=""`	A label for the frame — used by screen readers for accessibility
`width=""`	How wide the frame appears on your page, measured in pixels
`height=""`	How tall the frame appears on your page, measured in pixels
`src=""`	The web address of your Power BI report — the "what goes inside the frame"
`frameborder="0"`	Removes the visible border line around the frame — cleaner appearance
`allowFullScreen="true"`	Gives viewers the option to expand the report to fill their entire screen
`</iframe>`	Closes the frame — tells the webpage "the frame ends here"

Nothing exotic. Nothing mysterious.

Eight attributes with eight straightforward jobs.

The Two You Will Most Likely Need to Adjust

Most of this code you will never touch. But two attributes are worth paying attention to — width and height.

Width and Height — Getting the Size Right

By default, Power BI sets the width to 800 and the height to 600. These are measured in pixels — the tiny dots that make up everything on a screen.

On a large desktop monitor, 800 pixels wide looks reasonable. On a smaller laptop screen or a mobile device, it might appear too wide — causing horizontal scrolling, which feels clunky and unprofessional.

Here are three practical sizing approaches:

Scenario	Recommended Setting
Fixed desktop layout	`width="800" height="600"`
Full-width responsive layout	`width="100%" height="600"`
Tall report with many visuals	`width="100%" height="900"`

Using width="100%" instead of a fixed pixel number tells the frame to stretch and fill whatever container it sits inside — making it naturally responsive on different screen sizes. This is almost always the better choice.

A Note on Responsive Design

Responsive design simply means your webpage adjusts itself to look good on any screen size — desktop, tablet, or phone. Using width="100%" is a small but meaningful step toward that goal.

If your website already uses a responsive theme or template — which most modern WordPress, Wix, and Squarespace sites do — setting your iFrame width to 100% ensures the report fits neatly within your page layout at every screen size.

It is a one-word change that makes a significant difference.

Your Code Is Ready — Keep It Handy

At this point you should have your iFrame code copied and saved in a text editor.

Double check that it is complete — starting with <iframe and ending with </iframe>.

A missing character at either end will cause the embed to fail, showing nothing on your page.

Everything intact?

Good.

Time to put it to work.

IX. Step 6 — Embed the iFrame on Your Website

This is the moment everything comes together. You have your embed code ready. Now you are going to place it on your webpage — and watch your Power BI report appear live, right there on your site, interactive and fully functional.

The exact steps depend on which platform your website runs on. This guide covers the three most common scenarios.

Find yours and follow along.

Before You Begin — One Important Reminder

Your iFrame code should be copied and ready in your text editor.

If you closed it or lost it, go back to Power BI Service, open your report, and follow File → Embed Report → Publish to Web (public) to retrieve it again. Your previously generated code will still be there.

Option A — WordPress

WordPress powers over 40% of websites on the internet. It is the most likely platform you are working with. Here is exactly what to do.

Step-by-step:

Log into your WordPress admin dashboard at yoursite.com/wp-admin
Navigate to the page or post where you want the report to appear
Click Edit to open it in the block editor
Click the + icon to add a new block
In the search box that appears, type "Custom HTML" and select it
A plain text block will appear on your page
Click inside it and paste your iFrame code using Ctrl+V (or Cmd+V on Mac)
Click Preview in the top right corner to see how it looks
If everything looks right — click Update or Publish

That is it. Your report is now embedded on your WordPress page.

The Custom HTML block is your best friend for embedding anything on WordPress — not just Power BI reports. Once you know it is there, you will use it again and again.

Option B — Wix or Squarespace

Both platforms handle iFrame embedding through a dedicated HTML element. The approach is slightly different from WordPress but equally straightforward.

For Wix:

Open your page in the Wix Editor
Click the + Add Elements button on the left panel
Select Embed Code → Embed HTML
A grey placeholder box will appear on your page
Click Enter Code inside that box
Paste your iFrame code into the code window
Click Apply and then Save
Drag and resize the element on your page as needed

For Squarespace:

Open your page in the Squarespace Editor
Click the area where you want the report and select Edit
Click the + button to add a new content block
Choose Code from the block options
Paste your iFrame code into the code block
Click Apply and then Save

Option C — Raw HTML Page

If you manage a plain HTML website — where you directly edit .html files — the process is the most direct of all three options.

Step-by-step:

Open your .html file in any text editor — Notepad, VS Code, Sublime Text, or any other
Find the spot in your page where you want the report to appear
Paste your iFrame code directly between the opening <body> and closing </body> tags like this:

<body>

  <h1>My Data Report</h1>

  <iframe 
    title="My Power BI Report"
    width="100%" 
    height="600" 
    src="https://app.powerbi.com/view?r=xxxxxxxxxxxx" 
    frameborder="0" 
    allowFullScreen="true">
  </iframe>

</body>

Save the file
Upload it to your web server using your usual method — FTP, your hosting control panel, or your deployment tool

What a Successful Embed Looks Like

When you preview your page, you should see your Power BI report rendering cleanly inside the page — charts visible, layout intact, no login prompt appearing. It should look and feel like a natural part of your webpage, not a foreign object dropped onto it.

⚠️ Warning — Some Platforms Restrict iFrames

A small number of website platforms and hosting environments block iFrame content by default for security reasons. If you paste your code and see a blank space where the report should be, this may be the cause.

Quick checks to try:

Switch to a different browser and test again
Temporarily disable any security or caching plugins if you are on WordPress
Check your platform's documentation for iFrame or embed restrictions
Contact your hosting provider if the issue persists

Most of the time, one of these steps resolves it immediately.

10.

X. Step 7 — Test and Verify Your Live Embed

Your report is embedded. Your page is published. Before you share the link with anyone — pause. One final step separates a confident publish from an embarrassing one.

You need to test it. Properly.

Why Testing Matters More Than You Think

Here is the thing about embedded reports. Everything might look perfect when you view it — because you are logged into Power BI, your browser has cached data, and your account has full access.

But your visitors? They are coming in cold. No login. No cache. No account.

What you see and what they see can be surprisingly different.

Testing your embed without your login active is the only way to know for certain what the rest of the world actually sees when they land on your page.

There is a simple, free way to simulate exactly that.

The Incognito Window Test

Every major browser has a private or incognito mode. In this mode, your browser starts fresh — no stored logins, no cached data, no cookies.

It is the closest thing to stepping into a stranger's shoes without leaving your desk.

How to open an incognito window:

Browser	Shortcut
Google Chrome	Ctrl + Shift + N (Windows) / Cmd + Shift + N (Mac)
Mozilla Firefox	Ctrl + Shift + P (Windows) / Cmd + Shift + P (Mac)
Microsoft Edge	Ctrl + Shift + N (Windows) / Cmd + Shift + N (Mac)
Safari	Cmd + Shift + N (Mac)

Once the incognito window is open, navigate to the webpage where you embedded your report. Type the full URL into the address bar and press Enter.

Your Verification Checklist

Work through each of these carefully.

Do not rush.

✅ The report loads without asking for a login

If a Power BI sign-in prompt appears, your embed code was generated using the organizational setting instead of the public setting. Go back to Power BI Service and regenerate the code using Publish to Web (public).

✅ All visuals render completely

Scroll through the entire report. Look for blank tiles, spinning load indicators that never resolve, or error messages inside individual visuals.

Any of these signals a problem with the underlying dataset or a publishing issue worth investigating before sharing.

✅ Filters and slicers respond to interaction

Click on a slicer. Apply a filter.

Hover over a data point to trigger a tooltip.

Interactive elements should respond immediately and update the visuals in real time. If they do not, the embed is likely loading a static snapshot rather than the live report — check your embed code source URL.

✅ The layout fits the page cleanly

Look at how the report sits within your webpage. Is it cut off on the right side? Is there unwanted horizontal scrolling? Does it look cramped or oversized? If any of these are true, revisit your iFrame width and height values from Step 5 and adjust accordingly.

✅ The data appears current and accurate

If your report connects to a live data source, confirm the numbers and dates shown are up to date.

If the data looks stale, your dataset may not be set up to refresh automatically.

That is covered briefly in the next section and in more detail under best practices.

A Quick Note on Mobile

While you are testing, pull out your phone and open the same page in your mobile browser. Power BI reports embedded via iFrame do not always adapt gracefully to small screens — particularly if you used fixed pixel values for width and height.

If the report appears too small, too wide, or requires awkward zooming, go back and change your iFrame width to width="100%". That single adjustment resolves the majority of mobile display issues.

Full mobile optimization is a deeper topic — one worth exploring as a next step once your embed is working well on desktop. For now, making it functional and reasonably visible on mobile is the right goal.

When Everything Checks Out

If your report loads cleanly, displays correctly, responds to interaction, and requires no login — congratulations. Your embed is working exactly as intended.

Your Power BI report is now live on the web. Accessible to anyone.

On any device. Without requiring a single Power BI account.

That is no small thing.

XI. Troubleshooting — When Things Don't Go as Expected

Let's be honest. Technology does not always cooperate on the first try. Something looks wrong. The report is not showing. A message appears that you did not expect.

It happens to everyone — beginners and the experienced users alike.

This section is your calm, practical reference for the most common problems. No panic needed. Every issue listed here has a clear, workable solution.

How to Approach a Problem

Before diving into specific fixes, adopt this simple mindset:

Every problem has a cause. Every cause has a fix. Your job is simply to identify which one you are dealing with — then apply the right solution.

Work through this section methodically. Read the symptom. Check the cause. Apply the fix. Test again.

Problem 1 — Blank White Box Where the Report Should Be

You embedded the code. You published the page. But instead of your report, there is just an empty white rectangle staring back at you.

Likely Causes:

The iFrame code was copied incompletely — a character missing at the start or end
The platform you are using restricts iFrame content by default
A browser extension is blocking embedded content

Fixes to Try — In This Order:

Go back to Power BI Service and re-copy the embed code from scratch — do not edit it manually
Paste it fresh into a clean Custom HTML block or embed element
Disable any ad-blocking or security browser extensions temporarily and reload the page
Try viewing the page in a completely different browser
Check your website platform's settings for iFrame or embed restrictions and enable them if available

Problem 2 — "This Content is Blocked" Message

Your browser is displaying a security warning inside the iFrame area instead of the report.

Likely Cause:

Your browser's security settings are preventing third-party content from loading inside the page. Some corporate networks and strict browser configurations block iFrame content entirely.

Fixes to Try:

Open the page in a different browser — Chrome tends to be the most permissive for this
Check if you are on a corporate or institutional network that filters external content — try on a personal network or mobile data connection instead
If you manage the website server, ensure your site is running on HTTPS — Power BI embeds will not load correctly on unsecured HTTP pages

This is one of the most commonly overlooked issues. A site running on HTTP instead of HTTPS will almost always block Power BI iFrame content. Check your address bar — it should show a padlock icon and begin with https://

Problem 3 — "You Need Permission to View This Report"

A sign-in prompt or permission error appears instead of the report — even in incognito mode.

Likely Cause:

The embed code was generated using the organizational embedding option rather than Publish to Web (public). The report is set to require a Power BI login to view.

Fix:

Return to your report in Power BI Service
Click File → Embed Report → Publish to Web (public)
Generate a fresh embed code
Replace the old iFrame code on your webpage with the new one
Test again in incognito mode

This resolves the issue in virtually every case.

Problem 4 — Report is Showing Old or Outdated Data

Your report is visible and loading correctly — but the data it shows is not current. Numbers are from last week. Dates are wrong. Something is clearly stale.

Likely Cause:

Your dataset in Power BI Service is not set to refresh automatically. When you published your report, it uploaded a snapshot of your data at that moment in time. Without a scheduled refresh, it stays frozen in time.

Fix:

In Power BI Service, go to My Workspace
Find your Dataset — not the report, the dataset beneath it
Click the three-dot menu beside it and select Settings
Under Scheduled Refresh, toggle it on and set a refresh frequency that suits your needs — hourly, daily, or weekly
Save your settings

Note — scheduled refresh requires a Power BI Pro account and that your data source supports automatic refresh. Local Excel files, for example, cannot be refreshed automatically once uploaded. Cloud-based sources like SharePoint, SQL Server, or Google Sheets can.

Problem 5 — Report Appears Cut Off or Too Small

The report is loading but it is cropped on one side, or it is tiny and hard to read.

Likely Cause:

The width and height values in your iFrame code are too small for the content inside the report, or they are fixed pixel values that do not adapt to your page layout.

Fix:

Return to the HTML where your iFrame code lives
Change the width value to width="100%" for a responsive, full-width display
Increase the height value — try height="800" or height="900" for reports with multiple visuals stacked vertically
Save and preview the page again

Adjust incrementally until the report displays completely without scrollbars or cutoff edges.

Problem 6 — The Publish to Web Option is Missing From the Menu

You clicked File → Embed Report and the Publish to Web (public) option simply is not there.

Likely Cause:

Your organization's Power BI administrator has disabled the Publish to Web feature for security or compliance reasons. This is common in corporate and institutional environments.

Fix:

This is not something you can resolve on your own.

Contact your Power BI administrator and request that the feature be enabled for your account.

If you are the administrator, the setting is found in the Power BI Admin Portal under Tenant Settings → Export and Sharing Settings → Publish to Web.

Quick Reference Troubleshooting Table

Symptom	Most Likely Cause	First Fix to Try
Blank white box	Incomplete code or platform restriction	Re-copy embed code from scratch
Content blocked message	Browser security or HTTP site	Switch browser or enable HTTPS
Permission or sign-in prompt	Organizational embed used	Regenerate using Publish to Web (public)
Outdated data showing	No scheduled refresh set	Enable scheduled refresh on dataset
Report cut off or tiny	Fixed pixel dimensions too small	Change to `width="100%"`, increase height
Publish to Web option missing	Admin has disabled the feature	Contact your Power BI administrator

XII. Best Practices — Do This, Not That

You know how to publish. You know how to embed. You know how to troubleshoot. That already puts you ahead of most people attempting this for the first time.

But knowing how to do something and knowing how to do it well are two different things.

This section is the difference between a functional embed and a professional one.

These are not rules. Think of them as hard-earned lessons — the kind that usually only come after making the mistake first.

1. Always Preview Before You Publish Live

This sounds obvious. It gets skipped constantly.

Before you hit publish on any page containing an embedded report, preview it in your browser. Then preview it in incognito mode. Then check it on your phone.

A broken embed on a live page is visible to every visitor the moment they arrive. A broken embed in preview costs you nothing but thirty seconds.

Make the preview step non-negotiable. Every single time.

2. Never Embed Sensitive Data Using the Public Method

Publish to Web (public) means exactly what it says — anyone on the internet can view that report. No login. No restriction. No barrier of any kind.

That is powerful. It is also a serious responsibility.

Never use public embedding for reports containing:

Personal identifiable information — names, addresses, ID numbers
Financial records — salaries, account balances, transaction details
Medical or health-related data
Confidential business intelligence — unreleased figures, internal forecasts
Any data that could cause harm if seen by the wrong person

For sensitive reports, always use organizational embedding instead. It requires viewers to authenticate with a Power BI account before the report loads — keeping your data protected.

When in doubt, ask yourself this: "Would I be comfortable if this data appeared on the front page of a newspaper?" If the answer is no — do not embed it publicly.

3. Use Percentage-Based Width for Better Responsiveness

You saw this in Step 5. It is worth repeating here because it makes such a visible difference.

Setting	Result
`width="800"`	Fixed — may overflow on small screens, leaving empty space on large ones
`width="100%"`	Flexible — fills its container naturally at every screen size

Default to width="100%" unless you have a specific reason to use fixed dimensions. Your report will look cleaner on desktop, tablet, and mobile without any additional effort.

4. Set Up Scheduled Data Refresh

A report showing last month's data is not a live report. It is a photograph of one.

If your Power BI report connects to a data source that updates regularly — a database, a SharePoint list, a cloud spreadsheet — set up a scheduled refresh in Power BI Service so your embedded report always reflects current information.

Quick reminder on how:

Go to My Workspace in Power BI Service
Find your Dataset
Click the three-dot menu → Settings
Enable Scheduled Refresh and set your preferred frequency

Your visitors will always see fresh, accurate data. That is what makes an embedded report genuinely useful rather than merely decorative.

5. Keep Your Workspace Organized

This becomes important faster than you expect. Publish two or three reports and your workspace can start to feel cluttered — datasets, reports, and dashboards all listed together without clear labeling.

Simple habits that save time later:

Give every report a clear, descriptive name before publishing — not "Report 1" or "Final Final v3"
Use separate workspaces for separate projects if you have Pro access
Delete old or test embed codes you are no longer using — Power BI Service lets you manage these under File → Embed Report → Publish to Web (public) → Manage Embed Codes

A tidy workspace means faster updates, less confusion, and no accidental edits to the wrong report.

6. Revisit and Re-Test After Every Major Report Update

When you make significant changes to your Power BI report in Desktop and republish it, the embed code itself does not change — the same iFrame code continues to point to the same report location in the cloud. That is convenient.

However, layout changes, new pages, resized visuals, or added filters can all affect how the report displays within your existing iFrame dimensions. Always re-test your embedded page after a major update.

Specifically check:

✅ Nothing is cut off with the existing height setting
✅ New report pages or tabs are accessible within the embed
✅ Any new interactive elements — slicers, drill-throughs — work correctly

7. Use Descriptive iFrame Titles for Accessibility

Remember the title="" attribute inside your iFrame code? Most people leave it as the default or ignore it entirely.

That attribute exists for screen readers — the tools used by visually impaired visitors to navigate webpages. A descriptive title like title="Quarterly Sales Performance Report" tells screen readers exactly what the frame contains, making your content accessible to a wider audience.

It takes five seconds to update. It makes a meaningful difference to people who rely on assistive technology.

<iframe 
  title="Quarterly Sales Performance Report"
  width="100%" 
  height="700" 
  src="https://app.powerbi.com/view?r=xxxxxxxxxxxx" 
  frameborder="0" 
  allowFullScreen="true">
</iframe>

Small effort. Real impact.

8. Consider Your Page Load Speed

iFrames add external content to your page — and external content takes time to load. A heavy Power BI report with many visuals and a large dataset can noticeably slow down your webpage, particularly on mobile connections.

A few ways to manage this:

Place the embedded report lower on the page — below your main content — so the page loads quickly for visitors before the report begins rendering
Simplify your report where possible — fewer visuals per page means faster loading
Avoid embedding multiple Power BI reports on the same webpage

Your visitors' first impression of your page is formed in the first two seconds. Make sure those two seconds are fast.

zzz
13.

XIII. Conclusion — You Opened the Door. Now Walk Through It.

Something shifted today.

You did not just learn a technical process. You dismantled a wall — the invisible one that sits between powerful data and the people who need to see it.

That wall has stopped countless analysts, business owners, students, and creators from sharing work that genuinely deserved an audience.

You walked straight through it.

Think About What Just Happened

A few moments ago — or a few focused hours ago — you had a report trapped on your computer.

Beautiful, accurate, useful. And completely invisible to the world.

Now?

It is live. It is interactive. It is accessible to anyone, anywhere, on any device, at any hour, without a single prerequisite on their end.

No software to install. No account to create. No email attachment to open. No screen-share call to schedule.

Just a webpage. And your data, breathing inside it.

That is not a small feat. That is the difference between data that informs and data that transforms.

The Road You Travelled

You did not skip steps. You did not cut corners. You followed the full journey — and that matters more than most people realize.

Step	What It Represented
Built and verified the report	Respecting your audience before they ever arrive
Published to Power BI Service	Giving your work a permanent home in the cloud
Generated the embed code	Unlocking the door between your data and the world
Understood the iFrame code	Owning the process — not just following it blindly
Embedded it on your webpage	Placing your work exactly where it belongs
Tested it like a visitor	Seeing through someone else's eyes before they arrive
Learned to troubleshoot	Building the confidence to fix what breaks — because things always break

Every step meant something. Every step made the next one possible.

What You Actually Built Today

Here is what most tutorials will never tell you.

The iFrame is not the point. The embed code is not the point. Power BI Service is not the point.

The point is access.

The point is that someone — a colleague reviewing last quarter's numbers, a client checking their project metrics, a student exploring public data for the first time, a visitor landing on your portfolio at midnight from the other side of the world — can now see exactly what you built.

Interact with it.

Understand something because of it.

That is what data is for. Not to sit in files. Not to live in tools. Not to exist only for the people who built it.

Data exists to be understood. You just made yours understandable.

Most people who build great reports never share them effectively. You are no longer most people.

Where the Road Goes Next

You have earned the right to be curious about what comes next. Here are three paths worth walking when you are ready — each one a natural extension of what you have already learned.

🔐 Row-Level Security — Personalized Data for Every Viewer

Imagine the same report showing different data to different people. A regional manager sees only their region. A client sees only their account. A department head sees only their team.

Row-Level Security makes that possible. One report. Infinite personalization. Your next mountain to climb.

🔄 Scheduled Data Refresh — A Report That Never Goes Stale

A report showing yesterday's data is history. A report showing today's data is intelligence. Scheduled refresh connects your embed to live, automatically updating data sources — so your webpage always reflects the present moment without you lifting a finger.

🏢 Power BI Premium — Enterprise-Grade Embedding

For organizations that need authenticated, secure, deeply customized embedding built into their own applications — Power BI Premium and the Embedded API open a world far beyond iFrames. Developer territory, yes. But the foundation you built today points directly toward it.

One Last Thing Before You Go

Close this guide. Open Power BI Desktop. Open your report.

Do not wait until it is perfect. Do not wait until you feel completely ready. Do not wait for a better time that may never quite arrive.

Publish it.

Embed it.

Share the link.

Right now — while the steps are fresh, while the confidence is hot, while the momentum is yours to keep.

Because here is the truth about learning something new. The guides, the steps, the screenshots, the explanations — none of it fully belongs to you until you do it yourself, without anyone holding your hand, and watch it work.

That moment — when your report loads on your webpage in an incognito window and you realize you did that — is the moment this becomes a skill and not just a memory of something you once read.

Go get that moment. You have earned it.

Thank You for Following Along

Technical writing exists for one reason — to make the complex feel possible. If something in this guide clicked for you. If one analogy made something land. If one step saved you an hour of frustration. Then this guide did exactly what it was supposed to do.

Your data deserved to be seen.

Now it is.

🚀 Your Next Move Starts Here

Reading this guide was step one. Doing it is step two. Do not let step two wait.

✅ Take Action Right Now

If you are ready to publish your first report:

Open Power BI Desktop right now. Your .pbix file is waiting. Follow the seven steps in this guide — start to finish — and have your report live on the web before you close your browser today. Not someday. Today.

If you found this guide helpful:

Share it with someone who is sitting on a Power BI report they have never published. A colleague. A classmate. A fellow analyst drowning in data that nobody else can see. One share could be the reason someone finally gets their work in front of the audience it deserves.

If you got stuck somewhere along the way:

Drop your question in the comments below. Describe exactly where things went sideways — which step, what you saw, what you expected. No question is too basic. Every question helps someone else who is stuck in the exact same place but too afraid to ask.

If you want to go deeper:

Subscribe so you do not miss next level topics when they land.
Each one is a guide in its own right. Each one builds directly on the foundation you laid today.

💬 One Little Ask

If this guide took you from confused to confident — if something clicked that never clicked before — take thirty seconds and leave a comment below telling us where you got stuck before and what finally made it make sense.

Your experience is a breakthrough for someone else waiting to happen.

Data deserves to be seen. So does the work that goes into explaining it. Thank you for reading — now go build something worth sharing.

Article complete. Introduction rewritten. Conclusion memorable. CTA clear, strong, and multi-directional — covering action takers, sharers, strugglers, and growth seekers all in one unified close.

Ready to compile the full article, format it for your target platform, or begin the next piece whenever you are.

=================================================================

XIII. Conclusion — You Did It. Now What?

Take a moment. Seriously.

You started this guide with a Power BI report sitting quietly on your computer — visible only to you, useful only in theory. Now that same report is live on the web.

Interactive.

Accessible to anyone, anywhere, on any device. No developer hired. No complicated code written.

No guesswork.

That is a genuine skill you have built today.

The Journey You Just Completed

Let's walk the full path one final time — not to repeat what you already know, but to let it land as the cohesive, logical process it always was.

Stage	What You Did
1. Built It	Created a Power BI report in Desktop and confirmed it was ready
2. Published It	Sent the report to Power BI Service — your cloud home base
3. Verified It	Confirmed the report rendered correctly before touching embed settings
4. Generated the Code	Used Publish to Web to create a live iFrame embed code
5. Understood the Code	Broke down every attribute so nothing felt like a black box
6. Embedded It	Placed the code on your webpage — WordPress, Wix, or raw HTML
7. Tested It	Verified the live embed through an incognito window like a real visitor

Seven steps. One complete, working solution.

What Makes This Powerful

Most people who build great reports never share them effectively. The data stays locked inside a tool that only they can access.

Insights go unseen.

Decisions get made without the information that could have improved them.

You have changed that dynamic entirely.

An embedded Power BI report is not just a visual on a webpage. It is a live, breathing data resource — one that updates automatically, responds to interaction, and communicates information clearly to people who need it.

That has real value. In a business context. In an academic setting. In a personal portfolio.

Anywhere data matters — which is everywhere.

Where to Go From Here

You are no longer a beginner at this. But there is always a next level. Here are three directions worth exploring when you are ready — each one building naturally on what you have already learned.

📌 Row-Level Security (RLS)

What if you want different viewers to see different data within the same report? A regional manager seeing only their region's numbers. A client seeing only their account data.

Row-Level Security lets you control exactly that — filtering what each viewer sees based on who they are. It is a powerful feature that transforms a single report into a personalized experience for every user.

🔄 Scheduled Automatic Data Refresh

You touched on this in the best practices section. Going deeper means connecting Power BI to live cloud data sources — SQL databases, SharePoint lists, Google Sheets, APIs — and configuring refresh schedules so your embedded report always reflects the most current information without any manual intervention.

A truly live dashboard. Fully automated.

🏢 Power BI Premium and Advanced Embedding

For organizations that need authenticated embedding — reports that require login but are embedded in custom web applications rather than just iFrames — Power BI Premium and the Power BI Embedded API open up a much deeper set of capabilities.

This is developer territory. But knowing it exists means you know where the ceiling is — and that there is a path through it when you are ready.

Your Next Action — Right Now

Do not let the momentum stop here.

Open Power BI Desktop. Open your report. Follow the seven steps. Get it live.

Not tomorrow. Not when things are perfect. Today. The process is fresh in your mind right now and that is the best possible time to put it into practice.

The best way to truly learn something is to do it once on your own — without a guide holding your hand. You have everything you need.

A Final Thought

Technical skills feel intimidating from the outside. Complex, jargon-filled, gatekept by people who seem to have been born knowing this stuff. But every skill — including this one — breaks down into a series of logical, learnable steps.

You just proved that.

🤔 Here Is Something Worth Thinking About

You now know how to embed a Power BI report on any webpage in the world. No login required. No software needed. Just a browser and a link.

That is a genuinely powerful thing to be able to do.
But here is the question nobody asks until they have already done it —

What are you going to do with it?

A public sales dashboard? A live project tracker for a client?

A data portfolio that proves your analytical skills better than any resume ever could?

A community resource that gives your audience something real to interact with?

The embed is just the beginning. What comes next is fully in your hands.

👇 Tell us in the comments — what report are you planning to embed, and who is the audience you are finally going to share it with?

"Your Data Is Talking. . . Is Power BI Listening?"

Amailuk Joseph — Tue, 31 Mar 2026 19:21:47 +0000

Understanding Data Modeling in Power BI: Joins, Relationships, and Schemas Explained

A plain-English guide to the concepts that make your reports actually make sense.

Your Report Looks Fine. BUT... your Model Is Lying to You.

The numbers add up. The chart renders. The dashboard looks exactly like what your manager asked for.

Then someone changes the date slicer — and three visuals stop responding.

A colleague filters by region — and the revenue total doubles.

You add one more table — and nothing makes sense anymore.

The visuals did not break. The model underneath them was never right to begin with.

This is the silent killer of Power BI reports.
Not bad data.
Not weak DAX.
Not a missing chart type.

A model that was never properly built — because nobody showed you how, and Power BI lets you skip that step entirely.

Until the cracks show.

The Step Most Tutorials Skip

Search "Power BI tutorial" right now. Every top result goes straight to visuals — drag a field, pick a chart, add a slicer, publish.

Done.

What they skip is the 20 minutes of work that determines whether any of those visuals will ever, be trustworthy:

the data model.

How your tables connect. What role each one plays. Which relationships are active. Which schema holds the whole thing together.

That invisible structure is why one report scales and another collapses.

Why one analyst's numbers are always right and another's are always almost right.

The difference is not talent. It is the model.

What You Will Walk Away With

This is not a survey of concepts. It is a complete, ground-up guide — written for anyone who has heard the words "data modeling" and felt the floor shift slightly under their feet.

By the end you will be able to:

Explain data modeling in plain English — to yourself and to others
Use all six SQL joins — knowing exactly which one to reach for and why
Build relationships in Power BI with full control over cardinality, direction, and behavior
Choose the right schema — Star, Snowflake, or Flat Table — without guessing
Handle role-playing dimensions the way professionals do
Spot and fix the most common modeling mistakes before they corrupt a report
Build a complete Star Schema from four raw tables — step by step, from zero

We go from "I've heard of Power BI" to "I can model data with confidence" — and we do it in plain language, with real examples, at every step.

No jargon gates.
No assumed knowledge.
No skipped steps.

Here Is What We Are Going To Cover

Stop	Topic	What You Will Learn
1	What Is Data Modeling?	The foundation everything else builds on
2	SQL Joins	How data combines — all 6 joins explained
3	Fact vs. Dimension Tables	The two roles your tables play
4	Power BI Relationships	How to connect tables the right way
5	Schemas	Star, Snowflake, Flat Table — and when to use each
6	Role-Playing Dimensions	One table, many jobs
7	Common Modeling Mistakes	The traps and how to dodge them
8	Build Your First Model	A full walkthrough from zero to hero

One thing before we start.

Data modeling is one of those subjects where the first explanation you receive tends to shape everything that follows.

A bad one makes it feel harder than it is. A good one makes you wonder why it ever seemed complicated.

That is the only goal here.

Let us get into it.

Section 1: What Is Data Modeling?

Think of It Like Organizing a Kitchen Before You Cook

Imagine two kitchens.

In the first one, ingredients are everywhere. Flour is next to the dish soap. The eggs are behind the blender. Nothing is labeled. You could cook in there — but every meal starts with a 20-minute search.

In the second kitchen, everything has a place. Spices are grouped. The fridge is stocked logically. You walk in, and cooking just flows.

Data modeling is how you turn the first kitchen into the second — before you cook a single report.

So What Exactly Is It?

Data modeling is the process of deciding how your tables connect, what role each one plays, and how they talk to each other inside Power BI.

It is not about the visuals. It is not about colors or charts. It is the invisible structure that makes everything on the surface work correctly.

When your data is modeled well:

Filters flow across tables the way you expect
Numbers calculate correctly without hacks
Your report scales without breaking

When it is not modeled? Your slicer filters one table and ignores the rest. Your totals are wrong. Your date table does nothing.

The visuals did not fail you. The model did.

Where Does This Happen in Power BI?

Power BI gives you three workspaces. Each one has a job:

View	What You Do Here
Power Query Editor	Clean and shape your data before it loads
Model View	Connect your tables — this is where modeling lives
Report View	Build visuals on top of your model

Most beginners skip straight to Report View. That is the first mistake.

Model View is your kitchen layout tool. It is where you draw the lines between tables, define how they relate, and set the rules that every visual on every page will follow.

The One Sentence That Changes How You See Power BI

Here it is:

Your reports are only as smart as the model underneath them.

A well-built model makes DAX easier, reports faster, and dashboards that actually answer the right questions. A broken model creates workarounds that stack on top of each other until the whole thing collapses.

You do not need to be an expert to model data well. You need to understand a handful of core concepts — and that is exactly what the rest of this article covers.

Section 2: SQL Joins — Basically, Who Gets to Sit at the Table?

Before Power BI can model anything, your data has to be in the right shape.

Sometimes that means combining two tables into one. That is what a join really does.

A join answers one question: when two tables share a common column, which rows make the cut?

The answer depends on which join you use. There are six of them. Each one has a different rule about who gets included — and who's left out.

The Setup — One Analogy, Six Outcomes

We will use the same scenario for every join so the differences are crystal clear.

You are running a small online store. You have two tables:

Table A — Orders (what customers bought)

OrderID	CustomerID	Product
1001	C01	Laptop
1002	C02	Mouse
1003	C03	Keyboard
1004	C04	Monitor

Table B — Customers (who your customers are)

CustomerID	CustomerName
C01	Andrea
C02	Brian
C03	Carmen
C05	David

Notice: C04 placed an order but is not in the Customers table.

On the other hand, David (C05) is a registered customer but has no order.

These two mismatches are exactly what makes each join behave differently.

1. INNER JOIN — Only the Matches Show Up. . .

The rule: Return rows that exist in both tables.

No match?

No row.

Real life: You are hosting a dinner party. Only guests who both RSVP'd and show up get a seat.

Result:

OrderID	CustomerID	Product	CustomerName
1001	C01	Laptop	Andrea
1002	C02	Mouse	Brian
1003	C03	Keyboard	Carmen

C04's order disappears — no matching customer. David disappears — no matching order. Only the overlap survives.

Use it when: You only want clean, fully matched records.

3. RIGHT JOIN — Everyone From the Right, With Matches From the Left

The rule: The mirror version of a Left Join.

Return all rows from the right table. Matches from the left if available.

Real life: Every customer is listed. If they placed an order — great. If not, they appear with a blank order.

Result:

OrderID	CustomerID	Product	CustomerName
1001	C01	Laptop	Andrea
1002	C02	Mouse	Brian
1003	C03	Keyboard	Carmen
(blank)	C05	(blank)	David

David now appears — he is in the right table. C04 is gone — no customer record on the right.

Use it when: Your right table is the priority and the left is supplementary.

💡 Honest note: In practice, most analysts reorder their tables and use a Left Join instead of a Right Join. The result is identical — it is just easier to reason about "all rows from my main table."

4. FULL OUTER JOIN — Nobody Gets Left Out, Its A Party!

The rule: Return all rows from both tables. Match where possible. Fill blanks everywhere else.

Real life: The most inclusive guest list under the sun. Every order and every customer appears — matched or not.

Result:

OrderID	CustomerID	Product	CustomerName
1001	C01	Laptop	Andrea
1002	C02	Mouse	Brian
1003	C03	Keyboard	Carmen
1004	C04	Monitor	(blank)
(blank)	C05	(blank)	David

Both the unmatched order (C04) and the unmatched customer (David) appear.

Use it when: You need a complete picture — every record from both sides, matched or not. Great for auditing data gaps.

5. LEFT ANTI JOIN — Left-Side Loners Only

The rule: Return rows from the left table that have no match on the right. Matched rows are excluded.

Real life: Find every order that has no customer record. These are your data gaps.

Result:

OrderID	CustomerID	Product
1004	C04	Monitor

Only C04 appears — the one order with no matching customer.

Use it when: You are hunting for missing or unmatched records. A data quality goldmine.

6. RIGHT ANTI JOIN — Right-Side Loners Only

The rule: The mirror version of the Left Anti. Return rows from the right table with no match on the left.

Real life: Find every customer who has never placed an order.

Result:

CustomerID	CustomerName
C05	David

Only David appears — registered but never ordered.

Use it when: You want to find records that exist on one side but are completely absent from the other. Useful for finding inactive users, unassigned records, or orphaned data.

All Six Joins at a Glance

Join Type	What It Returns
INNER	Matched rows only
LEFT	All left rows + matched right rows
RIGHT	All right rows + matched left rows
FULL OUTER	Everything from both sides
LEFT ANTI	Left rows with NO match on the right
RIGHT ANTI	Right rows with NO match on the left

How to Do This in Power BI

Joins in Power BI live inside Power Query, under the Merge Queries feature. Here is how to use it:

Step 1 — Open Power Query
In Power BI Desktop, click Transform Data in the Home ribbon. Power Query Editor opens.

Step 2 — Select your primary table
In the Queries panel on the left, click the table you want as your left table — in our example, Orders.

Step 3 — Open Merge Queries
In the Home ribbon, click Merge Queries. A dialog box opens.

Step 4 — Configure the merge

The top section shows your left table (Orders).
Use the dropdown to select your right table (Customers).
Click the matching column in each table — CustomerID in both.
At the bottom, select your Join Kind from the dropdown: Inner, Left Outer, Right Outer, Full Outer, Left Anti, Right Anti.

Step 5 — Expand the joined columns
After clicking OK, a new column appears in your table. Click the expand icon (two arrows) in the column header to choose which fields from the right table to bring in.

Step 6 — Close and Apply
Click Close & Apply in the Home ribbon. Your merged table loads into the model.

Joins vs. Relationships — What Is the Difference?

You just learned how joins work. But Power BI has another way to connect tables — Relationships — and they are not the same thing.

Here is the short version:

	Joins (Power Query)	Relationships (Model View)
Where	Power Query Editor	Model View
What it does	Literally combines tables into one	Logically links separate tables
When	During data preparation	During modeling
Result	A new merged table	Tables stay separate, filters flow between them

Think of a join as a marriage — two tables merge and become one.

A relationship is a phone line — two tables stay separate but can talk to each other.

Knowing which one to use, and when, is one of the most important modeling decisions you will make.

We cover Relationships fully in Section 4. For now, remember this distinction — it will matter.

Section 3: Fact vs. Dimension Tables — The Scoreboard and the Player Cards

Every table in your data model plays one of two roles.

It is either recording what happened — or explaining who or what was involved.

That distinction has names: Fact tables and Dimension tables.

Understanding them is not optional.

They are the grammar of data modeling.

Get them wrong and your schema, your relationships, and your DAX all suffer for it.

The Basketball Analogy

Picture a basketball game.

The scoreboard tracks the action — points scored, time of possession, fouls committed, shots attempted. Every event gets recorded with a number and a timestamp.

The scoreboard does not care about backstory. It just logs what happened.

The player cards tell you everything else — a player's name, position, team, height, jersey number, hometown. Context. Description. Identity.

In data modeling:

The scoreboard = Fact Table
The player cards = Dimension Tables

One records events and measures. The other provides the context that makes those events meaningful.

Fact Tables — The Numbers and Events

A Fact table records transactions, events, or measurements. Each row is one thing that happened.

In a retail business, a Fact table might look like this:

OrderID	CustomerID	ProductID	DateID	Quantity	Revenue
1001	C01	P05	20240315	2	199.98
1002	C03	P12	20240316	1	49.99
1003	C01	P07	20240318	3	89.97

Notice what lives here:

ID columns — foreign keys that point to dimension tables
Numeric columns — the measures you will actually aggregate (sum, average, count)

A Fact table is typically long and narrow — many rows, relatively few columns. It grows every time something happens.

Common Fact table examples:

Sales transactions
Website events (clicks, page views, sessions)
Financial transactions (payments, refunds, charges)
Inventory movements

Dimension Tables — The Context

A Dimension table describes the who, what, where, and when behind each fact.

Using the same retail example:

Customers Table

CustomerID	CustomerName	City	Segment
C01	Andrea	New York	Retail
C03	Carmen	Austin	Wholesale

Products Table

ProductID	ProductName	Category	Price
P05	Wireless Mouse	Accessories	99.99
P12	USB Hub	Accessories	49.99
P07	Laptop Stand	Ergonomics	29.99

Dimension tables are typically short and wide — fewer rows, more descriptive columns. They grow slowly, if at all.

Common Dimension table examples:

Customers
Products
Dates (the most important dimension in almost every model)
Stores / Locations
Employees

How to Tell Them Apart in Your Own Data

When you are staring at a table and not sure which type it is, ask these three questions:

1. Does each row represent a single event or transaction?
→ If yes, it is probably a Fact table.

2. Are most columns numeric and meant to be summed or averaged?
→ If yes, it is probably a Fact table.

3. Does the table mostly describe something — a person, a product, a place?
→ If yes, it is a Dimension table.

The Date Table — A Dimension Worth Its Own Mention

If you build reports in Power BI, you will eventually need a Date table — and it is the single most important dimension in most models.

A proper Date table has one row per day and columns like:

DateID	Date	Year	Quarter	Month	MonthName	Weekday	IsWeekend
20240101	01/01/2024	2024	Q1	1	January	Sunday	Yes

Why does this matter?

Because Power BI's time intelligence functions — TOTALYTD, SAMEPERIODLASTYEAR, DATESYTD — only work reliably when you have a proper, unbroken Date table connected to your Fact table.

💡 Pro tip: Mark your Date table as an official date table in Power BI. Right-click the table in Model View → Mark as Date Table. This unlocks full time intelligence support.

Why This Distinction Drives Everything Else

You cannot build a clean Star Schema without knowing which tables are facts and which are dimensions.

You cannot set up relationships correctly without understanding which table holds the many side and which holds the one side — and that comes directly from this fact/dimension split.

You cannot write efficient DAX without knowing where your measures live (Fact tables) and where your filters come from (Dimension tables).

In short: every concept that follows in this article is built on top of what you just learned.

Right now, someone you know is staring at a broken Power BI report right now wondering why their slicer does not work.

Share this with them. The foundation is always the fix.

Next in this series → **DAX Fundamentals: writing measures, calculated columns, and time intelligence — built on top of the model you just learned to build.

Section 4: Power BI Relationships — Joins' Smarter Sibling

You learned that joins combine tables into one.

Relationships do something different — and in most Power BI models, more powerful.

Instead of merging tables, relationships keep tables separate while letting them communicate.

Filters flow. Measures calculate across tables. Slicers work report-wide.

The tables stay independent. The model becomes intelligent.

Joins vs. Relationships — The Final Word

Before we go deeper, lock this in:

	Joins (Power Query)	Relationships (Model View)
Where	Power Query Editor	Model View
What it produces	One merged table	Two connected tables
Data storage	Combined into one	Each table stays separate
Best for	Shaping data before loading	Connecting tables for analysis
Filter behaviour	Not applicable	Filters flow between tables

Use a join when you need to reshape your data.
Use a relationship when you need your tables to talk to each other during analysis.

Most real models use both — joins in Power Query to clean and prep, relationships in Model View to connect.

The Four Things That Define Every Relationship

Every relationship in Power BI is described by four properties. Understanding each one is non-negotiable.

1. Cardinality — How Many. . . to How Many?

Cardinality describes how many rows on one side of a relationship match rows on the other side.

Power BI supports three types:

One-to-Many (1:M) — The Gold Standard

One row in Table A matches many rows in Table B.

Example: One customer can place many orders. The Customers table has one row per customer. The Orders (Fact) table has many rows per customer.

Customers (1)	Orders (Many)
C01 — Andrea	Order 1001, 1005, 1009
C02 — Brian	Order 1002
C03 — Carmen	Order 1003, 1007

This is the relationship type you will use most. It is clean, performant, and exactly what a Star Schema is built on. When in doubt, aim for 1:M.

Many-to-Many (M:M) — Powerful, Handle With Care

Many rows in Table A match many rows in Table B.

Example: One product can appear in many orders. One order can contain many products.

Power BI supports M:M relationships natively, but they come with risks:

Filter ambiguity — filters can behave unexpectedly
Performance cost on large tables
Harder to debug when totals look wrong

💡 Best practice: Before accepting an M:M relationship, ask if a bridge table can resolve it into two clean 1:M relationships. It usually can — and your model will thank you.

One-to-One (1:1) — Rare but Valid

One row in Table A matches exactly one row in Table B.

Example: One employee record links to exactly one payroll record.

1:1 relationships are uncommon. When you see one, ask whether the two tables should simply be merged into one.

Often the answer is yes.

Use 1:1 only when keeping the tables separate serves a clear purpose — security, source system constraints, or deliberate separation of concerns.

2. Active vs. Inactive Relationships — The Starter and the Bench Player

Power BI only allows one active relationship between any two tables at a time.

The active relationship is the default. It is the one Power BI uses automatically when you build visuals and write measures. It appears as a solid line in Model View.

An inactive relationship is a backup — it exists in the model but does nothing until you explicitly call it. It appears as a dashed line in Model View.

When do you need an inactive relationship?

When the same two tables need to connect in more than one way.

The most common example: a Date table connected to a Sales Fact table on both Order Date and Ship Date. Power BI can only activate one at a time. So you make Order Date the active relationship and Ship Date the inactive one — then call it when needed using USERELATIONSHIP() in DAX.

We cover this fully in Section 6 on Role-Playing Dimensions. For now, just remember: solid line = active, dashed line = inactive.

3. Cross-Filter Direction — Which Way Do Filters Flow?

When you select a value in a slicer or filter a visual, Power BI applies that filter across related tables. Cross-filter direction controls which way that filter travels.

There are two settings:

Single — Filter flows one way only

The filter moves from the "one" side to the "many" side.

Example: Filtering the Customers table (one side) filters the Orders table (many side). But filtering Orders does not filter back into Customers.

This is the default. It is safe, predictable, and right for most models.

Both — Filters flow in both directions

Filters travel across the relationship in either direction.

This sounds convenient — and sometimes it is. But bidirectional filtering introduces a real risk: filter ambiguity. When multiple paths exist for a filter to travel, Power BI can produce unexpected or incorrect results.

⚠️ Rule of thumb: Start with Single. Switch to Both only when you have a specific reason — and test your numbers carefully when you do.

Bidirectional filters in M:M relationships are especially prone to silent errors.

4. The Relationship Line Notation in Power BI

When you look at Model View, the lines between tables are not just decorative. They tell you everything about the relationship at a glance:

What You See	What It Means
1 on a line end	That table is the "one" side
* on a line end	That table is the "many" side
Solid line	Active relationship
Dashed line	Inactive relationship
Single arrow	Single cross-filter direction
Double arrow	Bidirectional cross-filter

Learn to read these at a glance and Model View becomes a diagnostic tool, not just a canvas.

How to Create and Manage Relationships in Power BI

There are two ways to create relationships in Power BI. Use whichever fits your workflow.

Method 1 — Drag and Drop in Model View

In Power BI Desktop, click the Model View icon on the left sidebar (looks like three connected shapes).
Locate the two tables you want to connect.
Click and drag the shared column from one table to the matching column in the other.
Power BI creates the relationship and draws the line automatically.
Double-click the relationship line to open its properties and review cardinality and cross-filter direction.

This is the fastest method for building a model from scratch.

Method 2 — Manage Relationships Dialog

Go to the Home ribbon → click Manage Relationships.
A dialog shows all existing relationships in your model.
Click New to create a relationship manually.
Select your two tables from the dropdowns.
Click the matching column in each table's preview grid.
Set Cardinality and Cross-filter direction using the dropdowns at the bottom.
Click OK → Close.

This method is better for editing existing relationships or when your model has many tables and drag-and-drop becomes difficult to manage.

A Relationship Checklist Before You Move On

Before you leave Model View and start building visuals, run through this:

[ ] Every Fact table is connected to its Dimension tables
[ ] All relationships are 1:M where possible
[ ] No unintended M:M relationships exist
[ ] Cross-filter direction is Single unless you have a specific reason for Both
[ ] Your Date table is connected to your Fact table on the correct date column
[ ] Active vs. inactive relationships are set deliberately — not by accident

A model that passes this checklist is a model you can build on with confidence.

Section 5: Schemas — Star, Snowflake, or Flat Table. Which House Do You Build?

You know what Fact and Dimension tables are.

You know how relationships connect them.

Now the question is: how do you arrange them?

That arrangement has a name — a schema. Think of it as the floor plan of your data model. The tables are the rooms. The relationships are the doorways.

The schema is the blueprint that determines how everything fits together.

There are three schemas you need to know. Each one suits a different situation.

Choosing the wrong one does not necessarily break your model immediately — it just makes everything harder over time.

Schema 1: The Star Schema — The Industry Favourite

The Star Schema is the most widely used structure in Power BI and business intelligence. If you only learn one schema, make it this one.

The structure:
One Fact table sits at the center. Dimension tables surround it, each connected by a single 1:M relationship. When you draw it out, the shape looks exactly like a star.

A retail Star Schema looks like this:

Table	Type	Role
Sales	Fact	Records every transaction
Customers	Dimension	Describes who bought
Products	Dimension	Describes what was bought
Date	Dimension	Describes when it happened
Stores	Dimension	Describes where it happened

Every Dimension table connects directly to the Fact table. No Dimension connects to another Dimension.

That directness is the point.

Why Power BI loves the Star Schema:

Filters travel a short, predictable path — one hop from Dimension to Fact
DAX measures are easier to write and debug
Query performance is faster because relationships are simple
Model View stays readable even as the model grows

Use the Star Schema when:

You are building a report or dashboard for business users
Performance matters
You want a model that is easy to maintain and hands off

The honest limitation:
Star Schemas require some denormalization — meaning you may store repeated values across Dimension tables rather than normalizing them out.

That is a deliberate trade-off.

Readability and speed win over storage efficiency in most BI contexts.

Schema 2: The Snowflake Schema — The Star That Grew Branches

The Snowflake Schema is a Star Schema where the Dimension tables have been normalized — broken down further into their own related tables.

Where a Star Schema has one Products table, a Snowflake might split it into Products → Subcategory → Category. Each level becomes its own table, connected in a chain.

The structure looks like this:

Same retail model, Snowflake style:

Table	Connected To
Sales (Fact)	Products, Customers, Date, Stores
Products	Sub-Category
Sub-Category	Category
Customers	City
City	Region

When does a Snowflake Schema make sense?

Mostly when your data comes from a normalized relational database — like an enterprise data warehouse — and restructuring it into a flat Star Schema is not practical. The Snowflake preserves the source structure.

The trade-offs are real:

	Star Schema	Snowflake Schema
Query speed	Faster	Slower
Model complexity	Simple	More complex
DAX difficulty	Lower	Higher
Storage efficiency	Lower	Higher
Power BI performance	Better	Can degrade at scale

💡 The Power BI reality: Power BI is optimized for Star Schemas. Snowflake models work — but every extra hop between tables is an extra relationship for the engine to traverse.

In large models, that cost adds up.

If your source data arrives as a Snowflake, consider flattening the sub-dimension chains in Power Query before loading.

Use the Snowflake Schema when:

Your source system is already normalized and restructuring is not feasible
Storage efficiency is a hard requirement
You are working in a formal data warehouse environment

Schema 3: The Flat Table (Denormalized / Single Table) — Everything in One Room (Studio / Bedsitter)

The Flat Table is exactly what it sounds like. All your data lives in one wide table.

No relationships.

No separate dimensions.

Every column — measures, descriptions, dates, customer names — is in a single sheet.

What a Flat Table looks like:

OrderID	Date	CustomerName	City	ProductName	Category	Qty	Revenue
1001	2024-03-15	Andrea	New York	Wireless Mouse	Accessories	2	199.98
1002	2024-03-16	Carmen	Austin	USB Hub	Accessories	1	49.99

No joins needed. No relationships to configure. Everything is right there.

When it works:

Small, one-off analyses with a single clean data source
Quick exploration before committing to a full model
Data exported from a single system that does not need enrichment

When it breaks down:

The moment your data grows, the flat table becomes a liability:

Redundancy compounds — CustomerName and City repeat on every single order row
Updates become painful — if Andrea moves to Chicago, you update hundreds of rows instead of one
DAX gets messy — no clean dimension tables means filters and calculations have more to work around
Performance degrades — Power BI's engine is not optimized for one massive wide table

⚠️ The flat table trap: Many beginners bring an Excel file into Power BI and start building visuals directly on top of it.

That works — until it doesn't.

If your dataset will grow, or if you need to join additional sources later, invest the time to model it properly from the start.

Use the Flat Table when:

The dataset is small and self-contained
The analysis is exploratory or temporary
You are prototyping before building the real model

Which Schema Should You Use? — A Decision Guide

Not sure which one fits your situation? Work through this:

Start here: How many data sources are you working with?

One table, small dataset, quick analysis → Flat Table
Multiple tables you control → Star Schema (default choice)
Data from an enterprise warehouse you cannot restructure → Snowflake Schema

Then ask: Will this model grow over time?

Yes → Invest in a Star Schema now. A flat table will cost you later.
No → A flat table or simple Star Schema both work.

Then ask: Is query performance important?

Yes → Star Schema. Every time.
Not critical → Snowflake is acceptable if your source data demands it.

The Bottom Line

The Star Schema is not just a best practice recommendation — it is the shape Power BI's engine is built to work with. When your model looks like a star, Power BI performs at its best.

The Snowflake and Flat Table have their place. But. . . they are situational.

The Star Schema is the default.

Build your model like a star. Your reports — and your future self — will thank you.

Section 6: Role-Playing Dimensions — One Table, Many Hats

Some tables in your model are so useful they get called to duty more than once.

Not a copy.

Not a duplicate.

The same table, playing a different role depending on the context.

That is a role-playing dimension — and the Date table is almost always the one wearing multiple hats.

The Problem It Solves

Picture an e-commerce orders table. It has three date columns:

OrderID	OrderDate	ShipDate	DeliveryDate
1001	2024-03-01	2024-03-03	2024-03-06
1002	2024-03-02	2024-03-05	2024-03-09
1003	2024-03-04	2024-03-04	2024-03-07

Each column is a date. Each one means something different. And your business needs to analyze by all three — orders placed by month, shipments by week, deliveries by quarter.

You have one Date dimension table. You need it to serve three different relationships.

Power BI only allows one active relationship between two tables at a time.

That is the constraint role-playing dimensions are designed to solve.

How to Handle It in Power BI

There are two approaches. Which one you use depends on your model's complexity.

Approach 1 — One Date Table, Multiple Inactive Relationships

This is the most common approach.

In Model View, create your first relationship:
Date[Date] → Orders[OrderDate]
Set this as the active relationship.
Create a second relationship:
Date[Date] → Orders[ShipDate]
Power BI will automatically mark this as inactive (dashed line).
Create a third relationship:
Date[Date] → Orders[DeliveryDate]
Also inactive.

Now, by default, every date-related visual uses OrderDate — the active relationship does its job quietly in the background.

When you need to analyze by ShipDate or DeliveryDate, you activate the relevant relationship inside a DAX measure using USERELATIONSHIP().

The USERELATIONSHIP() Function — Plain English

USERELATIONSHIP() tells Power BI: "For this specific calculation, ignore the active relationship and use this inactive one instead."

Here is what it looks like in a DAX measure:

Revenue by Ship Date =
CALCULATE(
    SUM(Orders[Revenue]),
    USERELATIONSHIP(Orders[ShipDate], Date[Date])
)

What this does, line by line:

SUM(Orders[Revenue]) — add up all revenue
USERELATIONSHIP(Orders[ShipDate], Date[Date]) — but filter by ShipDate, not OrderDate

You are not changing the model. You are temporarily swapping which relationship is active for that one measure only. Everything else in your report keeps using OrderDate.

💡 This is why inactive relationships exist. They are not broken or forgotten relationships. They are deliberate standbys, ready to be called when the calculation needs them.

Approach 2 — Multiple Date Tables (One Per Role)

For complex models, some analysts create separate Date tables — one for each role:

Date_Order
Date_Ship
Date_Delivery

Each one is a full copy of the same Date table, each connected to its respective column in the Fact table with its own active relationship.

The benefit: every relationship is active. No DAX switching required. Simpler measures.

The trade-off: three tables to maintain instead of one. If your Date table needs updating — a new column, a fiscal year change — you update it in three places.

Which Approach Should You Use?

	One Date Table + Inactive Relationships	Multiple Date Tables
Maintenance	Update one table	Update each copy
DAX complexity	Requires USERELATIONSHIP()	Simpler measures
Model tidiness	Cleaner Model View	More tables to manage
Best for	Most models	Models with heavy time-based analysis

For most use cases — start with one Date table and inactive relationships. It keeps your model lean and your Model View readable. Reach for multiple Date tables only when your time intelligence needs are complex enough to justify the overhead.

The Takeaway

A role-playing dimension is not a workaround. It is a deliberate modeling pattern used by professionals across the industry.

When you see a Fact table with multiple date columns, you now know exactly what to do: one Date table, one active relationship, inactive relationships standing by, and USERELATIONSHIP() ready to call them into action.

That is not beginner thinking. That is how real models are built.

Section 7: Common Data Modeling Mistakes — The Traps Every Beginner Falls Into

A broken model rarely announces itself loudly.

It whispers. A total that looks slightly off. A slicer that filters one visual but ignores another.

A report that works perfectly — until someone adds a second page and everything falls apart.

Most of these quiet failures trace back to the same handful of mistakes.

Here they are — what causes them, what they look like, and how to fix them.

Mistake 1: Skipping the Model and Going Straight to Visuals

What happens:
You load your data, land in Report View, and start dragging fields onto the canvas. Things look fine — until they don't.

Totals are wrong. Cross-filtering breaks. You start writing complicated DAX to fix problems that a clean model would have prevented.

Why it happens:
Report View is where the exciting stuff lives.

The model feels like homework.

The fix:
Before building a single visual, open Model View. Check your relationships. Confirm your schema.

Ten minutes of modeling upfront saves hours of debugging later.

💡 Make it a habit: Model first. Report second.

Always.

Mistake 2: Unintended Many-to-Many Relationships

What happens:
Power BI detects a relationship between two tables but cannot determine which side is "one" and which is "many" — so it creates an M:M relationship.

Your visuals render.
Your numbers are wrong.
You have no idea why.

Why it happens:
The column you are joining on has duplicate values on both sides.

For a clean 1:M relationship, the "one" side must have unique values — no repeats.

Example:
Joining Orders to Products on ProductName instead of ProductID. If product names are not unique — two products called "Wireless Mouse" in different categories — Power BI cannot resolve the relationship cleanly.

The fix:

Always join on a column with unique values on the "one" side — typically an ID column, not a name column
In Model View, check the symbols on each end of the relationship line. You want 1 and * — not * and *
If you see * on both ends, investigate the source data for duplicates

Mistake 3: Bidirectional Filters Applied Without a Reason

What happens:
Cross-filter direction is set to Both on one or more relationships. Filters start flowing in unexpected directions. A visual that should show all products now shows only a subset. Totals shift depending on what else is filtered on the page.

Why it happens:
Bidirectional filtering sounds more powerful — and sometimes it is. But in models with multiple relationship paths, it creates filter ambiguity: Power BI has more than one route to travel and picks one, silently, without telling you.

The fix:

Default every relationship to Single cross-filter direction
Switch to Both only when you have tested the outcome and confirmed it is correct
If your numbers change unexpectedly after enabling bidirectional filtering — that is your sign to revert

Mistake 4: Using a Flat Table When the Data Has Outgrown It

What happens:
You import one wide table and build your report on top of it. Early on, everything works. Then the dataset doubles. Then someone asks for a new filter by region, and there is no clean Region column — just a City column with 400 unique values. Performance slows. Maintenance becomes painful.

Why it happens:
The flat table felt like the easy path at the start.

The fix:
If your dataset has clear descriptive attributes — customer details, product categories, geographic hierarchies — split them into dimension tables.

Even a simple three-table Star Schema (Fact + two Dimensions) is dramatically easier to work with than one sprawling flat table.

Mistake 5: Duplicate Rows Breaking Relationship Integrity

What happens:
Your relationship looks correct in Model View, but your measures are overcounting. A revenue total is double what it should be. A customer appears twice in a slicer.

Why it happens:
The "one" side of your relationship has duplicate values in the join column. When Power BI tries to resolve the relationship, it finds multiple matches and multiplies the result.

Example:
Your Customers dimension table has two rows for CustomerID C01 — one from an original import and one from a refresh that appended instead of replaced.

Every order for C01 now counts twice.

The fix:

In Power Query, apply Remove Duplicates on the key column of every Dimension table
Do this as a deliberate step during data preparation — not as an afterthought
Use the Column Quality feature in Power Query (View → Column Quality) to spot duplicate or error rates before loading

Mistake 6: No Proper Date Table

What happens:
You use the date column directly from your Fact table for time-based analysis. Some things work. But DAX time intelligence functions (TOTALYTD, SAMEPERIODLASTYEAR, DATESYTD) behave inconsistently or return blanks. Fiscal year filtering is impossible.

Why it happens:
Power BI's time intelligence functions require a dedicated, contiguous Date table — one row per day, no gaps, marked as a Date table — to work reliably.

The fix:

Create a dedicated Date table — either in Power Query, DAX using CALENDAR() or CALENDARAUTO(), or by importing one
Connect it to your Fact table on the date column
Right-click the table in Model View → Mark as Date Table → select the date column
Make sure the date range covers every date in your Fact table — no gaps, no missing days

Mistake 7: Inactive Relationships Left by Accident

What happens:
You create a relationship, Power BI detects a conflict with an existing one, and quietly marks the new relationship as inactive.

You do not notice.

Your visual filters by the wrong date column — or does not filter at all — and you spend an hour debugging DAX before realising the relationship was never active.

Why it happens:
Power BI creates inactive relationships silently. No alert. No warning. Just a dashed line you might not notice in a busy Model View.

The fix:

After creating any relationship, check the line — solid means active, dashed means inactive
Review all relationships periodically in Manage Relationships (Home ribbon) — the Active column shows you exactly which ones are live
If a relationship is inactive and you did not intend that, investigate whether it conflicts with an existing active relationship and resolve the ambiguity

The Mistake Prevention Checklist

Run through this before you publish any Power BI report:

[ ] Model View reviewed before first visual was built
[ ] All 1:M relationships confirmed — no unintended M:M
[ ] Cross-filter direction is Single unless deliberately changed
[ ] Dimension tables checked for duplicates on key columns
[ ] A proper, marked Date table is connected to the Fact table
[ ] All active vs. inactive relationships are set intentionally
[ ] Flat tables have been restructured if the dataset has grown

A model that clears this list is a model you can hand to someone else with confidence.

Section 8: Build Your First Data Model — From Zero to a Working Model

Every concept in this article has been building toward this moment.

Fact tables. Dimension tables. Relationships. Star Schema. Role-playing dimensions. Joins in Power Query. You have learned each one individually. Now we put them together — step by step, start to finish — and build a real, working data model in Power BI.

No shortcuts. No skipped steps. Just the process, exactly as it happens.

The Scenario

You work for a small retail business. You have been handed four CSV files:

File	What It Contains
`Sales.csv`	Every transaction — OrderID, CustomerID, ProductID, OrderDate, ShipDate, Quantity, Revenue
`Customers.csv`	Customer details — CustomerID, CustomerName, City, Segment
`Products.csv`	Product details — ProductID, ProductName, Category, Price
`Date.csv`	A full calendar table — Date, Year, Quarter, Month, MonthName, Weekday

Your job: connect these four tables into a clean Star Schema, handle the role-playing date dimension, and leave the model ready to report on.

Step 1 — Load Your Tables Into Power BI

Open Power BI Desktop.
On the Home ribbon, click Get Data → Text/CSV.
Select Sales.csv and click Load — or click Transform Data if you want to inspect it first in Power Query (recommended).
Repeat for Customers.csv, Products.csv, and Date.csv.
Once all four are loaded, you will see them listed in the Fields pane on the right side of your screen.

💡 Use Transform Data, not just Load. Clicking Transform Data opens Power Query Editor first, giving you a chance to check column types, spot errors, and remove duplicates before anything reaches your model. Make this your default.

Step 2 — Clean and Prepare in Power Query

With all four tables open in Power Query Editor, do a quick pass on each one.

For every table:

Check that column data types are correct — dates should be Date type, numbers should be Decimal or Whole Number, IDs should be Text
Click View → Column Quality to check for errors and empty values
On your key columns (CustomerID, ProductID, DateID), right-click the column header → Remove Duplicates — especially on Customers, Products, and Date

For the Sales table specifically:

Confirm both OrderDate and ShipDate columns are present and formatted as Date type
These two columns are what we will use to create active and inactive relationships in the next steps

When everything looks clean, click Close & Apply on the Home ribbon. Power Query closes and your data loads into the model.

Step 3 — Go to Model View

Click the Model View icon on the left sidebar — it looks like three connected shapes stacked vertically.

You will see your four tables laid out on the canvas, possibly in a cluttered arrangement. Power BI may have already detected and created some relationships automatically based on matching column names.

Before trusting auto-detected relationships:

Go to Home → Manage Relationships
Review every relationship Power BI created
Delete any that look incorrect or that connect the wrong columns
You are going to create the relationships deliberately — do not let auto-detection make decisions for you

Step 4 — Arrange Your Tables Into a Star Shape

This step is visual but important. A readable Model View is a maintainable model.

Drag the Sales table to the center of the canvas — it is your Fact table.
Drag Customers to the left.
Drag Products to the right.
Drag Date to the top.

Your canvas now physically resembles a star. That visual clarity is intentional — it makes relationships easier to create, easier to review, and easier to hand off to someone else.

Step 5 — Create Your Relationships

Now we draw the lines. Work through each relationship one at a time.

Relationship 1 — Sales to Customers

In Model View, drag CustomerID from the Sales table to CustomerID in the Customers table
Power BI creates the relationship
Double-click the line to verify: Cardinality = Many to One (*:1), Cross-filter direction = Single
Click OK

Relationship 2 — Sales to Products

Drag ProductID from Sales to ProductID in Products
Verify: Cardinality = Many to One (*:1), Cross-filter direction = Single
Click OK

Relationship 3 — Date to Sales (Active — Order Date)

Drag Date from the Date table to OrderDate in the Sales table
Verify: Cardinality = One to Many (1:*), Cross-filter direction = Single
This is your active relationship — the default for all date filtering
Click OK

Relationship 4 — Date to Sales (Inactive — Ship Date)

Drag Date from the Date table to ShipDate in the Sales table
Power BI will flag a conflict with the existing Date→Sales relationship and automatically mark this one as inactive (dashed line)
That is exactly what you want — confirm and click OK

Your model now has four relationships. Three solid lines. One dashed line.

Step 6 — Mark Your Date Table

Right-click the Date table in Model View.
Select Mark as Date Table.
In the dialog, select the Date column as the date column.
Click OK.

Power BI now recognizes this as an official Date table. Time intelligence functions — TOTALYTD, SAMEPERIODLASTYEAR, and others — will work correctly from this point forward.

Step 7 — Verify the Model

Before you build a single visual, run a final check.

Open Manage Relationships (Home ribbon) and confirm:

Relationship	Cardinality	Active	Cross-filter
Date → Sales (OrderDate)	1:M	✅ Yes	Single
Date → Sales (ShipDate)	1:M	❌ No	Single
Sales → Customers	M:1	✅ Yes	Single
Sales → Products	M:1	✅ Yes	Single

Everything checks out. Your Star Schema is built, your role-playing dimension is in place, and your Date table is marked and ready.

Step 8 — Test With a Simple Visual

Head to Report View. Build one quick visual to confirm the model is working:

Insert a Matrix visual
Add MonthName from the Date table to Rows
Add Revenue from the Sales table to Values
Add Category from the Products table to Columns

If the matrix populates correctly — months on rows, product categories on columns, revenue figures in the cells — your model is working. Filters are flowing from Dimensions to Fact exactly as designed.

What You Just Built

Step back and look at what you have:

Four tables — one Fact, three Dimensions
A clean Star Schema — optimized for Power BI's engine
Four deliberate relationships — cardinality and cross-filter direction set intentionally
A role-playing Date dimension — one active relationship, one inactive, ready for USERELATIONSHIP()
A marked Date table — time intelligence unlocked
A verified, tested model — visuals confirmed before the report is built

That is not a beginner's model. That is how production models are built.

Section 9: The Model Was Always the Point

Most people who open Power BI for the first time never make it this far.

They build a few visuals, hit a wall when the numbers stop making sense, and quietly decide that data work is "not for them."

Not know that the wall they hit was not a skill ceiling. It was a missing foundation — the one you just spent this entire article building.

You made it here. That matters more than you think.

What Just Changed

You did not just read about data modeling. You learned to see data differently.

You now look at a spreadsheet and ask: Is this a Fact table or a Dimension?

You look at two tables and ask: Should these be joined or related?

You look at a schema and know — immediately — whether it will hold under pressure or collapse the moment someone adds a new data source.

That shift in how you see data is not cosmetic.

It is the difference between someone who uses Power BI and someone who understands it.

Those two people sit in the same meetings, look at the same dashboards, and carry very different levels of quiet confidence.

You just moved from one group to the other.

The Thing Nobody Tells You About This Work

Here is what the tutorials, YouTube videos, and certification courses rarely say out loud:

The technical part is the easy part.

Joins, relationships, schemas — those are learnable.

You learned them today. What is harder — and what actually separates good analysts from great ones — is the discipline to model before you build.

To slow down at the start so everything accelerates after.

Most people skip the model because it feels like a waste of valuable time.

The best ones know it is the only thing that makes the work fast and & last.

What to Do Before This Week Is Over

Do not let this article become a bookmark you never return to.

Take any dataset you have — an Excel file, a work report, anything — and open Power BI.

Find your Fact table. Identify your Dimensions.

Build, even if its a simple three-table Star Schema. Create the relationships deliberately. Mark your Date table.

It does not have to be perfect. It just has to be intentional.

That first deliberate model is where everything you read today stops being knowledge and starts being skill.

There is no shortcut to that crossing. You just have to build something.

When you are ready to go deeper:

DAX is the natural next step — measures, calculated columns, and time intelligence that only work correctly on top of a model like the one you just learned to build
Power Query (M language) sharpens how you prepare and shape data before it ever reaches the model
Performance optimization — understanding how Power BI's Vertipaq engine reads your model will make you a stronger, faster, more deliberate modeler

Each one builds directly on what you learned here. The model is the foundation. It always was.

One Last Thing

Go back to the beginning of this article for a moment — not to re-read it, just to remember where you started.

You came in because something was broken or unclear.
A report that did not behave. A concept that never quite landed. A feeling that everyone else understood something you had not learned yet.

You were right. You had not learned it yet.

Now you have.

The broken slicer, the wrong totals, the filter that goes nowhere — you know what causes those now.

More importantly, you know how to build something that does not have those problems in the first place.

That knowledge does not expire. It does not get patched out in the next Power BI update.

The Star Schema you built today is the same Star Schema that runs inside the dashboards at companies you have heard of. The relationship principles you learned are the same ones a senior BI developer applies on day one of any new project.

You did not learn a trick. You learned the foundation.

Build on it.

Right now, someone you know is staring at a broken Power BI report right now wondering why their slicer does not work.

Share this with them. The foundation is always the fix.

Next in this series → **DAX Fundamentals: writing measures, calculated columns, and time intelligence — built on top of the model you just learned to build.

Tags: #PowerBI #DataModeling #DataAnalytics #BusinessIntelligence #SQL #StarSchema #DAX #PowerQuery #BeginnerToAdvanced #DataEngineering

How Excel is Used in Real-World Data Analysis

Amailuk Joseph — Mon, 23 Mar 2026 13:29:38 +0000

Every week, somewhere in the world, a data scientist opens a terminal, fires up Python, and writes elegant code to analyze a dataset.

And every week, in even far greater numbers, someone opens Excel — and gets the same job done before lunch!

I did not anticipate to write that sentence when I started my data science training at LuxDevHQ.

I came in ready to learn Python, obsessed with the idea of writing code that crunched millions of rows in milliseconds.

Excel felt like the thing you used before you knew better. The tool you graduated from.

Then my instructor dropped a 7,000-row sales dataset on my screen and said: "Analyze this. You have two hours."

I reached for Python. I spent forty minutes setting up the environment, importing libraries, and debugging a pandas error I had never seen before.

My classmate next to me who had quietly opened Excel was already building her second PivotTable!

She finished in ninety minutes. Her output was clean, visual, and ready to present.

Mine was still a stack of error messages.

That day, reset my entire perspective. . .

Excel is not the tool you use before you know better.

It is the tool professionals reach for when they need answers fast, when data lives in a spreadsheet and needs to stay there, and when the person waiting for your findings does not know what a DataFrame is!

In this article, I walk you through what Excel actually is, how it shows up in real-world data work. Delving thru features and formulas I have been learning at LuxDevHQ in the same logical order you would actually use them when working with real data.

Explaining them the way I wish it had been explained to me when I started.

What Is Excel, Really?

Microsoft Excel is a spreadsheet application developed by Microsoft and part of the Microsoft Office and its 365 suite.

At its most basic level, it organizes data into a grid of rows and columns, forming what are called cells.

Each cell can hold a value. Could be a number, text, a date, or a formula.

But calling Excel just a "spreadsheet tool" would be like calling a Swiss Army knife just a "small blade."

Excel is a full-featured environment for:

• Storing and organizing data
• Cleaning and transforming raw data
• Performing statistical and mathematical analysis
• Visualizing data through charts and dashboards
• Automating repetitive tasks with formulas and macros

It is available on Windows, Mac, and as a web application, making it one of the most accessible data tools in existence.

More importantly, it is used across virtually every industry; finance, healthcare, retail, logistics, human resources, marketing, and beyond.

How Does Excel Still Matters in a World of Python and SQL?

That is a fair question. With tools like Python, R, SQL, and Power BI becoming standard in data science, why are we still talking about Excel?

Here is the honest answer: most of the world's business data still lives in spreadsheets.

When a sales manager hand you a .xlsx file and needs answers by end of day, you are not spinning up a Jupyter notebook.

You open Excel, and you deliver.

Beyond accessibility, Excel has some unique advantages:

• Low entry barrier — almost every computer in a professional setting has it
• No setup or environment required — you open it and start working
• Great for quick Exploratory Data Analysis (EDA)
• Excellent for communicating findings to non-technical stakeholders who are comfortable with spreadsheets
• Bridges the gap between raw data and business decisions

At LuxDevHQ, we were taught that a good data scientist is a versatile one.

Excel is not a competitor to Python — it is a complement.

Real-World Use Cases of Excel in Data Analysis

Before diving into the features, let me paint a picture of where you will actually encounter Excel in the field.

1. Sales and Revenue Analysis

Sales teams use Excel to track monthly revenue, compare performance across regions, calculate growth rates, and forecast future sales. Analysts build dashboards that update dynamically as new data is entered.

2. HR and Workforce Analytics

HR departments use Excel to manage employee records, calculate attrition rates, analyze compensation data, and track recruitment pipelines. Conditional formatting helps flag outliers — like employees’ overdue for a performance review.

3. Financial Modelling

In finance, Excel is the industry standard. Analysts build complex models involving projections, scenario analysis, net present value calculations, and cash flow statements — all inside a spreadsheet.

4. Healthcare Data Tracking

Hospitals and clinics use Excel to monitor patient data, track inventory of medical supplies, analyze readmission rates, and manage appointment scheduling data.

5. Marketing Campaign Analysis

Marketers use Excel to analyze A/B test results, calculate conversion rates, track cost-per-acquisition, and measure return on investment (ROI) across campaigns.

In all of these scenarios, the workflow is roughly the same: get the data → clean it → analyze it → visualize it → communicate findings.

That is the pipeline I want to walk you through now, using the features I have learned so far.

Step 1: Getting Familiar with the Data

When you receive a dataset, the first thing you do is understand its structure.

• How many rows?
• What columns exist?
• Are there blanks?
• What data types are present?

In Excel, a few keyboard shortcuts become your immediately best c jumps to the last used cell, telling you the size of your dataset
• Ctrl + Shift + L — toggles filters on your headers so you can quickly sort and explore
• Freeze Panes (View → Freeze Top Row) — keeps your headers visible as you scroll through thousands of rows

These seem small, but they immediately tell you what you are working with.

Step 2: Cleaning the Data

Raw data is almost never analysis-ready.

It has duplicates, inconsistent text, extra spaces, missing values, and wrong formats. Hence data cleaning being where analysts spend most of their time.

And you guessed right, Excel has excellent tools for this.
TRIM() — Removing Extra Spaces

A common issue is hidden spaces in text fields that cause lookups and filters to fail silently.

=TRIM(A2)

This removes all leading, trailing, and excess internal spaces from the cell A2. Simple, but critical.

PROPER(), UPPER(), LOWER() — Standardizing Text Case

If one row says "lagos" and another says "LAGOS" and a third says "Lagos," Excel treats them as three different values.

These functions standardize text:

=PROPER(A2) → "Lagos"

=UPPER(A2) → "LAGOS"

=LOWER(A2) → "lagos"

IFERROR() — Handling Errors Gracefully

When a formula returns an error (like dividing by zero), it can break the downstream calculations. IFERROR wraps any formula and returns a fallback value instead of an error:

=IFERROR(B2/C2, 0)

This means: divide value in B2 by value in C2, but if that throws an error, return 0 instead.

Remove Duplicates

Under the Data tab, "Remove Duplicates" is a one-click tool that scans selected columns and deletes duplicate rows.

Always done after first creating a backup of your raw data.

Step 3: Exploring and Summarizing Data

Once the data is clean, analysis begins. The goal here is to extract meaningful summaries.

SUM(), AVERAGE(), COUNT(), MIN(), MAX()

These are the foundational aggregate functions every analyst uses daily:

=SUM(D2:D100) → Total revenue

=AVERAGE(D2:D100) → Average revenue per transaction

=COUNT(D2:D100) → Number of transactions

=MIN(D2:D100) → Lowest single transaction

=MAX(D2:D100) → Highest single transaction

COUNTIF() and SUMIF() — Conditional Aggregation

Here is where things get interesting.

In the real world, you rarely want to sum everything.

You want to sum revenue for a specific region, or count how many sales came from a given product.

COUNTIF counts cells that meet a condition:

=COUNTIF(C2:C100, "North")
→ "How many transactions came from the North region?"

SUMIF sums cells where a related column meets a condition:

=SUMIF(C2:C100, "North", D2:D100)
→ "What is the total revenue from the North region?"

These functions are workhorses in sales and marketing analysis.

SUMIFS() and COUNTIFS() — Multiple Conditions

When you need to filter by more than one criterion:

=SUMIFS(D2:D100, C2:C100, "North", E2:E100, "Q1")
→ "Total revenue from the North region in Q1"

Step 4: Looking Up and Combining Data

Real-world data rarely lives in one sheet. You might have a sales table and a separate customer details table, and you need to bring them together.

This is where lookup functions shine.

VLOOKUP() — Vertical Lookup

VLOOKUP searches for a value in the first column of a range and returns a corresponding value from another column in the same row.

=VLOOKUP(A2, CustomerTable, 3, FALSE)

Breaking this down:

• A2 — the value to look for (e.g., a Customer ID)
• CustomerTable — the range or table to search in
• 3 — return the value from the 3rd column of that range
•FALSE — find an exact match

Real-world example: You have a list of transactions with Customer IDs, and a separate customer table with names and email addresses.

VLOOKUP pulls the customer’s name into your transactions sheet automatically.

XLOOKUP () — The Modern Upgrade

XLOOKUP is the newer, more flexible replacement for VLOOKUP.

It is cleaner to write, works in both directions (not just left-to-right), and handles missing values natively:

=XLOOKUP(A2, CustomerTable[CustomerID], CustomerTable[CustomerName], "Not Found")

Step 5: Analyzing Patterns with PivotTables

If I had to name the single most powerful Excel feature for data analysis, it would be PivotTables.

A PivotTable lets you instantly summarize, group, filter, and cross-tabulate data — without writing a single formula.

Here is the scenario: you have 10,000 rows of sales transactions. You want to know total revenue by region, broken down by product category, for each month.

Writing formulas for that would take a long time. And I mean, a very long time.

A PivotTable does it in under 60 seconds.

How to create one:

Click anywhere inside your clean dataset
Go to Insert → PivotTable
Choose where to place it (new sheet recommended)
In the PivotTable Fields panel: o Drag Region to Rows o Drag Product Category to Columns o Drag Revenue to Values (set to Sum) o Drag Month to Filters

PivotTables are also dynamic. If the underlying data changes, you right-click and hit Refresh — and all your summaries instantly update.

Step 6: Visualizing Data

Numbers alone do not communicate.

Charts make patterns visible and findings convincing. Excel's charting tools are robust enough for most business reporting needs.

Choosing the Right Chart Type

Goal Chart Type

Compare categories Bar or Column Chart

Show trends over time Line Chart

Show proportions Pie or Donut Chart

Show distribution Histogram

Show relationships Scatter Plot

Building a Chart from a PivotTable
Once your PivotTable is ready, you can insert a PivotChart directly from it.

This creates a chart that stays linked to the PivotTable — when you change the filter, the chart updates too.

Conditional Formatting — Visual Analysis Without Charts
For quick pattern recognition within a table, Conditional Formatting applies color scales, data bars, or icon sets to cells based on their values.

Example: Apply a green-to-red color scale on the Revenue column — highest values glow green, lowest glow red. In seconds, you can visually identify your best- and worst-performing segments.

Step 7: Making Data Dynamic with Named Ranges and Data Validation

Named Ranges
Instead of referring to Sheet1!$D$2:$D$100 in every formula, you can name that range "Revenue" and use it like this:

=SUM(Revenue)

=AVERAGE(Revenue)

This makes formulas readable and easy to maintain — especially important when handing work to a colleague.

Data Validation
Data validation controls what can be entered into a cell. Common uses:

• Allowing only numbers within a specific range
• Creating a dropdown list to ensure consistent entries (e.g., only "North", "South", "East", "West" can be entered in the Region column)

This is crucial for maintaining data integrity — bad inputs are the root cause of most analysis errors.

Putting It All Together: A Mini Case Study

Let me close with a real scenario from a practice exercise at LuxDevHQ.

The Problem: A retail company gave us 12 months of transaction data — over 8,000 rows covering sales reps, regions, product lines, and revenue figures.

The question: Which region and product combination drove the most revenue in H2, and how does that compare to H1?

The Workflow:

Opened the raw .xlsx file and used Ctrl + End to confirm the dataset size
Cleaned the data — used TRIM () to fix text fields, removed duplicates, standardized region names with PROPER ()
Created a helper column using SUMIFS to calculate H1 and H2 revenue per row
Built a PivotTable with Region on rows, Product on columns, and Revenue (Sum) as values — filtered by half-year period
Added Conditional Formatting to highlight top-performing cells
Created a PivotChart (clustered bar chart) to visualize the comparison
Wrote a 5-line summary of findings directly below the chart, ready to be shared with the team

Total time: under 2 hours. And the output was clear, professional, and actionable.

Final Thoughts

Excel is not a beginner tool that you grow out of. It is a professional tool that grows with you.

The further you go in data analytics and data science, the more you appreciate having a solid foundation in Excel — because it trains you to think about data: how it is structured, how it should be cleaned, how summaries are built, and how stories are told through numbers.

As a student at LuxDevHQ, learning Excel alongside Python and SQL has shown me that the best analysts are not defined by which tool they use, but by how clearly, they can move from raw data to insight — whatever the tool in hand.

The Tool Does Not Make the Analyst — But It Reveals Them

The formulas and features in this article are just the beginning. But master these, and you will already be thinking like a data analyst.

The thing nobody tells you when you start learning data science: the tools are not the point.

The thinking is.

Excel does not make you a great analyst. Neither does Python. Neither does SQL.

What makes you a great analyst is the ability to look at a messy pile of numbers and ask the right questions — then pursue the answers with whatever is in your hands.

And that is what Excel does do, and better than almost anything else at this stage: it keeps you honest.

Every step is visible. Every formula is traceable. Every error is right there, staring at you from a cell, refusing to be hidden behind a stack trace or a silent script failure.

Excel forces you to understand your data before you summarize it, and understand your summary before you visualize it.

That discipline — that sequential, deliberate way of working — is not a limitation of the tool.

It is a lesson the tool is teaching you.

My classmate who finished her PivotTable in ninety minutes while I was drowning in pandas errors was not better at Excel than I was at Python.

She was better at thinking through data.

Excel just made that thinking visible.

I am still learning. We all are.

But every SUMIFS formula I write, every VLOOKUP I debug, every PivotTable I build from a chaotic spreadsheet — I am not just producing an output.

I am training a muscle.

*The muscle that asks: *
• What does this data actually say?
• What is it hiding?
• And what decision should it impact?

That muscle does not care what tool you use.

However, if you are just starting out, Excel is one of the best places to build it.

Personal Reflection

Learning Excel has genuinely changed my perception of data.

Earlier, I used to look at numbers as isolated values—figures on a screen without much meaning attached to them. But now, I naturally start asking questions.

What does this number represent?
Why does it change?
What story is it telling?

Working with Excel trained me to slow down and pay attention to structure—how data is organized, how small inconsistencies can affect results, and how a simple formula can reveal something deeper.

Even something as basic as cleaning a dataset made me realize that good analysis starts long before any insights appear.

What stands out the most is how Excel shifted my mindset.

I no longer rush to conclusions.

I Instead explore, test, and verify. I’ve become more curious and more intentional with data.

You could say, learning Excel didn’t just teach me a tool—it changed how I think.

So, the next time someone hands you a .xlsx file and expects answers — do not reach for something fancier.

Open Excel.

Trust the grid. And deliver.