DEV Community: Leah Kivuti

How to Publish a Power BI Report and Embed It on a Website (Step-by-Step Guide)

Leah Kivuti — Mon, 06 Apr 2026 07:21:06 +0000

When you first start using Power BI, it’s exciting to build dashboards and reports that turn raw data into something meaningful. But at some point, you’ll want to share your work with others in a way that’s simple, interactive, and accessible from anywhere.

That’s where publishing and embedding come in.

In this guide, I’ll walk you through how to take a report you’ve created in Power BI, publish it to the web, and embed it into a website. Whether you’re a student, a data analyst, or just someone exploring data tools, this process is an essential skill.

What is Power BI?

Power BI is a business intelligence tool developed by Microsoft that helps you analyze data and present it through interactive visuals like charts, graphs, and dashboards. Instead of static reports, Power BI lets users explore data by clicking, filtering, and drilling down into details.

You typically build reports in Power BI Desktop, then publish them to the Power BI Service, which is the online platform where your reports are hosted and shared.

Why Publish and Embed a Report?

Publishing your report allows you to:

Access it from anywhere
Share it with others easily
Collaborate with teams

Embedding takes it a step further by allowing you to display your report inside a website, blog, or portfolio. This is especially useful if you want to showcase your work or build data-driven applications.

Step 1: Create a Workspace

Before uploading your report, you need a workspace in Power BI Service. A workspace is like a container where your reports, dashboards, and datasets are stored.

Here’s how to create one:

Go to the Power BI Service in your browser
Sign in to your account
On the left sidebar, click on Workspaces
Click Create a workspace
Enter a name and click Save

Once created, your workspace will appear in the list and will be ready to use.

Screenshot idea: Show the workspace creation screen with the name field filled

Step 2: Publish Your Report from Power BI Desktop

Now that you have a workspace, the next step is to upload your report.

Open your report in Power BI Desktop
Click the Publish button in the top right corner
Select the workspace you created
Click Select

After a few seconds, your report will be uploaded.

To confirm:

Go back to Power BI Service
Open your workspace
You should see your report listed there

Screenshot idea: Publish button and success message

Step 3: Generate the Embed Code

Once your report is online, you can generate a code that allows it to be embedded into a website.

Open your report in Power BI Service
Click File
Select Embed report
Choose Publish to web (public)
Click Create embed code
Copy the iframe code provided

Important: This method makes your report publicly accessible. Anyone with the link can view it, so avoid using it for confidential or sensitive data.

Step 4: Embedding the Report on a Website

Once your report is published and you have generated the embed link in Power BI Service, the next step is to place it on a website.

In Power BI Service, open your report, click on File, then select Embed report, and choose Publish to web. If you haven’t done this before, you will be prompted to create an embed link. Once created, Power BI will give you a link that is used to display your report outside the platform.

To embed the report on a website, you need to use that link inside your website’s HTML editor. Most websites have a section where you can insert custom content, such as dashboards or videos. This is where the report goes.

If you are working with a simple website, you would place the embed link inside an embed container so that the report appears directly on the page. If you are using platforms like WordPress or Wix, you can use their built-in “embed” or “custom HTML” feature and paste the link there.

After adding the link, save your changes and open the page in a browser. Your Power BI report should now appear within the website, fully interactive. Users will be able to click on visuals, apply filters, and explore the data just like they would inside Power BI.

It’s always a good idea to test your page after embedding. Make sure the report loads correctly and fits well within the layout. You may need to adjust spacing or sizing depending on how your website is designed.

Here are a few things to keep in mind:

Make sure your visuals are clean and easy to understand before publishing
Use proper titles and labels so viewers can follow your report
Test your embedded report on different screen sizes
Avoid publishing sensitive data using public embed links

Final Thoughts

Publishing and embedding a Power BI report is one of the best ways to share your work with the world. It transforms your report from something that sits on your computer into something interactive that anyone can access online.

Once you get used to the process, it becomes very straightforward. Create a workspace, publish your report, generate the embed code, and place it on your website. That’s all it takes.

If you’re building a portfolio or working on data projects, this is a powerful way to present your work and stand out.

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

Leah Kivuti — Sat, 04 Apr 2026 09:02:48 +0000

Two weeks ago I had no idea what Power BI is, what data modeling means, or why people keep talking about joins and relationships. Everything sounded complicated and honestly, a bit overwhelming. But as I started learning step by step, I realized these concepts are actually very logical and easy to understand when explained in a simple way.

Let us start with joins, because that is where most people begin when working with data.

When working with data, we often have multiple tables that need to be connected. For example, you might have a customers table and a sales table. The customers table contains details like customer names, while the sales table contains transactions such as what was bought and how much was spent. These tables are connected using a common column like Customer ID.

This is where joins come in.

A join helps us combine data from two tables based on a common column. But not all joins behave the same way. Each type of join answers a different kind of question.

A left join keeps all the records from the left table and then checks if there is a match in the right table. If there is a match, it brings in the data. If there is no match, it still keeps the record from the left table and leaves the other side blank. This is useful when you want a complete list from one table and just want to see which ones have matching data in another table.

A right join does the opposite. It keeps all records from the right table and checks for matches in the left table. Even if there is no match, the records from the right table are still included.

A full outer join keeps everything from both tables. Whether there is a match or not, all records are included. This is useful when you want to see all possible data from both sides and identify where matches exist and where they do not.

An inner join is strict. It only keeps records that exist in both tables. If there is no match, the data is removed. This is useful when you only care about matching records.

Then we also have anti joins.

A left anti join shows records that exist in the left table but do not have a match in the right table. For example, customers who have never made a purchase.

A right anti-join shows records that exist in the right table but do not have a match in the left table. For example, transactions that are not linked to any known customer.

So every time we want to answer a question using joins, we must tell the system exactly how to connect the tables. We have to choose the type of join and apply it manually depending on what we are trying to achieve.

This is how things work in SQL and in many traditional data systems. However, Power BI works a bit differently, and this is where things become more interesting.

In Power BI, we do not usually write joins every time we build a report. Instead, we define relationships between tables once, and Power BI automatically uses those relationships whenever we create visuals.

A relationship is simply a connection between two tables using a common column. Once you define that connection, Power BI understands how data in one table relates to data in another table. This is what allows you to combine data from different tables in a single visual.

For example, imagine you are building a bar chart that shows customer names and total quantity purchased. The customer name comes from the customers table, while the quantity comes from the sales table. These fields are not in the same table, but because there is a relationship between them using Customer ID, Power BI is able to bring them together in one visual. Without that relationship, this would not be possible.

Relationships also allow filtering across tables. If you select a specific customer, the sales data automatically updates to show only that customer’s transactions. This happens because Power BI understands how the tables are connected. This brings out a key difference between joins and relationships.

Joins are temporary. You create them each time you need them, and they physically combine tables into one.

Relationships are more permanent. Once you define them, they stay in your model and are used automatically whenever you build reports, unless you remove them.

Understanding this difference is very important because it changes how you think about working with data in Power BI.

Instead of repeatedly combining tables, you focus on building a clean data model where tables are properly connected. Once that is done, everything else becomes much easier.
After understanding joins and relationships, the next important concept in data modeling is cardinality.

Cardinality describes the nature of the relationship between two tables. In simple terms, it explains how data repeats across tables. It helps Power BI understand how tables interact and how filters behave when you are building reports.

Most of the time, especially when working with fact and dimension tables, you will deal with one-to-many relationships. This is the most common type.

A one-to-many relationship means one record in one table is linked to many records in another table. For example, one customer can make many purchases. So in this case, the customer's table has one record for that customer, but the sales table can have multiple records for the same customer. When you look at it from the other direction, it becomes many-to-one, meaning many sales belong to one customer. It is the same relationship, just viewed differently.

The second type is one-to-one. This is less common and happens when each record in one table matches exactly one record in another table. A good example is an employee and their ID. One employee has one ID, and that ID belongs to only one employee. There is no duplication on either side.

The third type is many-to-many. This happens when multiple records in one table relate to multiple records in another table. For example, students and courses. One student can take many courses, and one course can have many students. These relationships can be more complex and should be handled carefully. In most cases, it is better to structure your data in a way that avoids many-to-many relationships where possible.

Now, let us connect this to fact and dimension tables.

A fact table stores transactions or events. It tells you what happened. For example, a sales table records each purchase, including values like quantity and total sales. Each row represents a single transaction.

A dimension table provides context to those transactions. It answers questions like who made the purchase, what was bought, and where it happened. For example, customers, products, and stores are all dimension tables because they describe the data in the sales table.

In most well-structured models, you will find one-to-many relationships between dimension tables and the fact table. One customer links to many sales, one product links to many sales, and one store links to many sales.

Now, let us look at how relationships are created in PowerBI.

Power BI can automatically detect relationships if columns have the same names. However, this is not always accurate. For example, it might try to connect two columns named city from different tables, even when they are not actually related. This can create incorrect relationships. Because of this, it is always important to review and create relationships manually.

To create or manage relationships, go to Manage Relationships in Power BI. From there, you can add a new relationship by selecting the two tables and choosing the common column. You also define the cardinality and confirm the connection.

Another way is to use Model View, where you can drag one column from a table and drop it onto a matching column in another table. It is also important to know that relationships can be active or inactive.

An active relationship is the one Power BI uses by default when building visuals. An inactive relationship exists in the model, but is not used unless you specifically activate it in your calculations. You can have multiple relationships between two tables, but only one can be active at a time.

One practical tip is to ensure your column names are clear and consistent. For example, renaming columns like ID to Customer ID, Product ID, or Store ID makes it easier to identify and create correct relationships.

In summary, cardinality helps define how tables are connected, fact tables store what happened, dimension tables describe what happened, and relationships bring everything together in Power BI. When these are set up correctly, your reports become much easier to build and understand.

Now, let us talk about filter direction, which is very important when working with relationships.

When you create a relationship, Power BI needs to know how filters should flow between tables. This is called cross-filter direction. In most cases, especially in a proper data model, filters flow from dimension tables to the fact table.

This means if you filter by customer, product, or store, it will affect the sales table. For example, if you select a specific customer, the sales data will automatically update to show only transactions related to that customer. The same happens if you filter by product or store. This is why relationships are so powerful.

For example, you can create a chart that shows the total quantity by customer name. The quantity comes from the sales table, while the customer name comes from the customers table. Because there is a relationship between them, Power BI is able to combine these fields correctly.

If the relationship does not exist, the visual will not work as expected. You might only see totals that do not break down properly, or Power BI might not know how to connect the data at all.

The same applies when using slicers.

Slicers are simply filters in Power BI. You can create slicers using fields like customer name, product name, or store name. When your relationships are set correctly, selecting a value in one slicer will affect all related visuals in your report.

For example, selecting a customer should update charts showing product sales and store performance. If this is not happening, it usually means your relationships are missing, incorrect, or inactive.

Power BI also allows two types of cross-filter direction.

Single direction is the default and most recommended. Filters flow in one direction, usually from dimension tables to the fact table. This keeps your model simple and avoids confusion.

Both directions allow filters to move in both directions between tables. This can be useful in some advanced scenarios, especially with many-to-many relationships, but it should be used carefully because it can create ambiguity and unexpected results.

In summary, after creating relationships, you must ensure they are correct, active, and properly configured. Renaming columns helps avoid confusion, removing incorrectly detected auto relationships improves accuracy, and understanding cross-filter direction ensures your data behaves as expected.

When all these are set correctly, your visuals, filters, and reports will work smoothly and give you accurate insights.

Now that we understand joins, relationships, cardinality, and filter direction, we can define data modeling more clearly.

Data modeling is the process of organizing your data into structured tables and defining how those tables relate to each other so that analysis becomes easy and meaningful. It is not just about connecting data, but about designing how that data should be structured from the beginning.

You decide what goes into the fact table, what belongs in dimension tables, and how everything connects. That structure is what we call a data model.

There are different ways to structure this model, and these are called schemas. Let us start with the simplest one, the flat table.

A flat table is a single table that contains all the data in one place. There are no separate fact or dimension tables, and there are no relationships. Everything is stored together.

Flat tables are very common because this is how data is usually collected or exported. For example, when you download data from a system or scrape data from the web, it often comes as one large table. They are easy to read and understand because everything is in one place. You can quickly look at the table and understand what is happening without needing to connect multiple tables.

However, flat tables are not ideal for analysis, especially when the data becomes large. One major issue is data duplication. The same values, such as customer names, product names, or locations, are repeated many times. This increases the size of the data and reduces performance.

Another issue is maintenance. If something changes, for example, a store location or a product name, you have to update it in many rows. This is time-consuming and can lead to inconsistencies. Flat tables can also become very large and slow as more data is added. This makes them harder to manage and less efficient for reporting.

Because of these limitations, we move from flat tables to more structured models called schemas.

Schemas help us organize data properly by separating it into fact and dimension tables and connecting them using relationships. This reduces duplication, improves performance, and makes analysis easier.

The two main schemas used in data modeling are the star schema ** and the **snowflake schema, which we will explore next.

A schema is simply the structure of how your tables are organized and connected. It defines how your data is arranged so that it is easy to understand and analyze.

The most common and most recommended schema in Power BI is the star schema.

A star schema is a structure where you have one central fact table, and then multiple dimension tables connected directly to it. When you look at it in Model View, it actually looks like a star, with the fact table at the center and the dimension tables spreading out around it.

For example, you can have a sales table at the center. This is your fact table because it stores transactions. Then you connect it directly to dimension tables like customers, products, and stores. All these dimension tables link directly to the sales table, not to each other.

As long as you have one central fact table and multiple dimension tables connected directly to it, you have a star schema. This is the most commonly used schema because it is simple, clear, and efficient.

First, it reduces data duplication compared to a flat table. Instead of repeating customer names, product names, or store details many times, you store them once in their own tables.

Second, it is easy to understand. You can quickly look at the model and identify the fact table and the dimension tables without confusion.

Third, it is easier to build and works very well with Power BI. It improves performance and makes reporting faster.

Because of these advantages, most professional Power BI models are built using the star schema.

In a star schema, the fact table stores events or transactions, while the dimension tables provide context. Relationships connect the tables, and cardinality defines how they relate.

However, there is another type of schema called the snowflake schema.

A snowflake schema is a more advanced version of the star schema. It starts as a star schema, but then the dimension tables are further broken down into smaller related tables.

This process of breaking down tables is called normalization.

Normalization means organizing data in such a way that reduces duplication and improves data consistency. Instead of storing the same information repeatedly in one table, you split it into multiple tables and connect them using IDs.

For example, instead of having a customer's table that contains customer name, city, county, region, and country all in one place, you can break it down.

You can have a customers' table with customer ID and city ID. Then you create a cities table that contains city details. That cities table can link to a counties table, and the counties table can link to a regions table.

So instead of repeating city, county, and region information for every customer, you store each piece of information once and connect them using relationships.

This creates a chain-like structure.

The fact table connects to a dimension table, which connects to another dimension table, and so on. This branching structure is what forms a snowflake schema.

Compared to the star schema, the snowflake schema has some advantages. It reduces data duplication even further. It improves data consistency because changes are made in one place. It works well for hierarchical data, such as city to county to region to country.

However, it also has disadvantages.

It is more complex to understand because it has more tables. It is harder to build and manage. It can slow down reporting if not designed properly. It is more difficult to debug when something goes wrong.

Because of this, the snowflake schema is usually used in more advanced scenarios, especially when dealing with very large datasets or hierarchical data.

In most cases, especially for beginners and for building dashboards, the star schema is the best choice.

To summarize, schemas define how your data model is structured. A star schema is simple, fast, and widely used, with one fact table connected directly to dimension tables. A snowflake schema is more complex, where dimension tables are further broken down into smaller related tables through normalization.

Understanding these two schemas is important because they form the foundation of how you design efficient and scalable data models in Power BI.

Common mistakes to avoid when building data models

Some common mistakes often happen when building data models, especially when you are still learning how Power BI works. One of the most frequent issues is missing relationships between tables. When tables are not properly connected, your visuals may not respond as expected. For example, if you have a patient's table and a visits table but you forget to relate them using a patient ID, selecting a specific patient will not correctly filter the visit records, leading to confusing or incomplete results.

Another common mistake is using the wrong type of relationship. For instance, if you incorrectly set up a many-to-many relationship when a one-to-many relationship would work, your results may become duplicated or inaccurate. A simple example is when one patient can have many visits, but each visit belongs to only one patient. If this is modeled incorrectly, Power BI may count or display values multiple times, which affects your analysis.

Keeping unnecessary columns in the fact table is also a problem. In a well-designed model, descriptive details such as patient name, doctor specialty, or department should live in dimension tables, not in the fact table. If you keep repeating these details in the fact table, you increase redundancy and make the dataset harder to manage. For example, instead of storing a patient’s name in every visit record, you store a patient ID in the fact table and keep the name in the patients table. This keeps the model clean and avoids repetition.

Another issue is overusing bi-directional filters. While bi-directional relationships can be useful in certain scenarios, using them everywhere can make your model complex and slow. For example, if you allow filters to flow both ways between a doctor's table and a visits table unnecessarily, a single filter might unexpectedly affect multiple tables in ways you did not intend, leading to confusing results. In most cases, a single direction from the dimension tables to the fact table is sufficient and safer.

Some people also overcomplicate their models by creating unnecessary snowflake schemas when a simpler star schema would work better. For example, instead of keeping patient, doctor, and department information in separate chains of tables, you could keep them as straightforward dimension tables directly connected to the fact table. Adding too many layers of related tables can make the model harder to understand and slower to query without adding real analytical value.

In simple terms, good data modeling is about keeping things clear, organized, and purposeful. When your tables are properly related, when each piece of information is stored in the right place, and when the schema is simple and efficient, your Power BI reports become easier to build, faster to run, and more reliable. For example, with a well-structured model of patients, doctors, diagnoses, and payments connected to a central visits table, you can easily answer questions like how many patients a doctor has seen, which payment methods are most common, or which diagnoses occur most frequently, without running into confusion or errors.

Power BI has significantly changed how I approach data and problem-solving. It has helped me move from viewing data as raw and disconnected information to seeing it as a structured and meaningful system that can tell a story. Through learning data modeling, relationships, and visualization, I am now able to organize datasets, connect different sources of information, and build dashboards that clearly communicate insights.

It has also improved my analytical thinking, making me more careful about how data is structured and how different pieces relate to each other. Overall, Power BI has strengthened both my technical skills and my confidence in working with data to support better decisions.

How Excel is Used in Real-World Data Analysis.

Leah Kivuti — Fri, 27 Mar 2026 10:39:54 +0000

When I first came across Excel, it honestly felt like just another program filled with endless rows, columns, and unfamiliar formulas. At that point, I didn’t really understand what it was meant for beyond simple calculations. I could add numbers, format a table, and that was about it. Everything else felt overwhelming and a bit intimidating. Looking back, that was the beginning of a journey that completely changed how I think about and work with data.

For the past month, I have been exploring data analysis using Excel. Excel is something I’ve seen used almost everywhere—in businesses, schools, and even in small personal projects. Over time, I’ve come to appreciate that it’s not just a spreadsheet tool. It’s more of a way to take raw, messy data and turn it into something that actually makes sense.

The Early Days: Struggling to Understand the Basics

In the beginning, things didn’t come easily. Writing formulas correctly or even referencing cells felt confusing. I remember making simple mistakes like missing brackets or getting errors that I didn’t fully understand.

The first functions I learned were things like SUM() and AVERAGE(). Even though they looked straightforward, it still took time to get comfortable using them. At that stage, I wasn’t just learning Excel—I was slowly learning how to think in terms of structured data.

Discovering the Power of Logic

As I continued practicing, I started using IF statements. That was a real turning point for me.

For the first time, Excel felt like more than just a tool for calculations. It could actually make decisions based on conditions. I could categorize values automatically instead of doing it manually. For example, labeling results as “Poor,” “Average,” or “Excellent” depending on the value.

That’s when it started to make sense that Excel isn’t just about storing data—it can interpret it too.

Learning to Work with Messy Data

One thing I quickly realized is that real-world data is rarely clean. I often came across missing values, inconsistent formatting, duplicates, and text that needed fixing.

To deal with this, I started using tools like:

Remove Duplicates
Text to Columns
TRIM
Basic techniques for handling blanks and errors

This part of the learning process taught me something important: before you analyze anything, you have to make sure the data itself is clean and reliable. Otherwise, the results won’t be meaningful.

Applying Excel to Real Data: The Jumia Dataset Experience

One of the most important parts of my learning journey was working with a real dataset from Jumia.

At first glance, it looked like a simple table of products with details like prices, discounts, ratings, reviews, and categories. But as I spent more time with it, I realized it represented something much bigger—a live marketplace where products compete, and customers express their opinions through ratings and reviews.

Each row represented a product, while the columns showed different attributes such as:

Product categories
Prices and discount percentages
Customer ratings
Number of reviews

However, the dataset wasn’t ready to use straight away. There were missing values, inconsistencies, and formatting issues that needed to be fixed first.

Cleaning the data took time and attention. I had to handle missing ratings, standardize values, remove inconsistencies, and make sure everything was structured properly before moving on to analysis.

Seeing Patterns in the Data

Once the data was clean, I started exploring it using PivotTables, charts, and conditional formatting.

At that point, things started to become more interesting. I began to notice patterns such as:

Products with more reviews often had more stable ratings
Some categories consistently performed better than others
Discounts seemed to influence how products were engaged with
Missing ratings pointed to gaps in the dataset

Instead of looking at individual products one by one, I started seeing relationships between pricing, ratings, and categories.

Turning Data into Insights

As I continued analyzing, the dataset started to tell a clearer story.

It became easier to see that:

Customer ratings and reviews play a big role in product performance
products with high discounts behave differently when it comes to engagement
Discounts may affect how products are perceived
Missing or incomplete data can limit the quality of insights

This experience helped me understand that Excel is not just for calculations—it’s a tool for uncovering patterns and making sense of real-world situations.

Building Dashboards

As I improved, I began combining different Excel features to build dashboards.

These dashboards included:

Charts to visualize trends
PivotTables for summaries
Conditional formatting to highlight important values
Key metrics that made the data easier to understand

This helped me move from working with raw data to presenting information in a way that is clear and easy to interpret.

Why Excel Matters to Me

Excel has become a very practical tool in my work and learning. I’ve seen how it can be used in different areas such as:

Financial analysis and budgeting
Sales and marketing analysis
Data cleaning and organization
Project tracking and management

Some of the features I rely on most include PivotTables, IF statements, VLOOKUP/XLOOKUP, charts, and conditional formatting. Each of these helps me work with data more efficiently and make better sense of it.

Final Thoughts

Looking back, learning Excel has changed the way I approach data. I no longer just see numbers—I look for patterns, relationships, and meaning behind them.

The moment I realized Excel could go beyond simple calculations was a big shift for me. It felt like I had uncovered another layer of understanding in the data. Numbers started to feel more like information that tells a story.

That’s really why I enjoy working with Excel. It helps turn raw data into something useful, and eventually into decisions that actually make sense.