Did you know you can create Power BI semantic models directly from the Fabric web portal? No Power BI Desktop required. This is a game-changer if you’re working on a MacBook, dealing with a locked-down corporate laptop, or just prefer working in the browser.
Today I’m going to show you how to create a semantic model from a Fabric lakehouse, set up relationships, create measures, and jump straight into building reports—all from your web browser. Let’s dive in.
Why Create Semantic Models in the Web Portal?
Sure, you can still create semantic models using Power BI Desktop—that’s the traditional approach. But what if you can’t install software on your machine? Or what if, like me, you’re working on a MacBook where running Power BI Desktop means dealing with virtualization or spinning up Azure VMs?
With Microsoft Fabric, you can create semantic models directly in the web browser. And here’s the best part: you can use Direct Lake as your storage mode. That means your data stays in the Fabric lakehouse, not in the Power BI semantic model itself. You get a direct connection to your lakehouse tables without importing anything. Pretty cool, right?
Starting Point: A Lakehouse with Data
For this demo, I’m using a lakehouse called “Gold” that contains the New York City Taxi and Limousine Commission open-source dataset. It’s got information on taxi rides, taxi types, dates, and pickup/dropoff locations—everything we need for a good dimensional model.
When you navigate to your lakehouse in the Fabric portal, you’ll see all your tables listed. From here, creating a semantic model is surprisingly simple.

Creating the Semantic Model
At the top of the lakehouse view, you’ll see a big button that says “New semantic model.” Click that, and you’re on your way.
Give your model a name—I’m calling mine “Taxi Analysis”—and then select which tables you want to include. For this example, I’m selecting:
- dim_dates (our date dimension)
- pickup_locations (pickup dimension)
- dropoff_locations (dropoff dimension)
- taxi_types (taxi type dimension)
- trip_data (our fact table)
Click confirm, wait a moment, and boom—your semantic model is created. The interface that opens up should look very familiar if you’ve used Power BI Desktop. It’s basically the same semantic modeling experience, just in your browser.
Organizing the Model View
The first thing I like to do is arrange the tables visually in the model view. I prefer to put my dimension tables on top and the fact table at the bottom. This way, the visual layout matches how filters trickle down from dimensions to facts. It’s not required, but it makes the model easier to understand at a glance.

Creating Relationships
Now we need to create relationships between our dimensions and fact table. If you’ve used Power BI Desktop, this will feel very familiar—it’s a simple drag-and-drop exercise.
Let’s start with the date dimension. I’ll drag the “date” field from dim_dates and drop it onto the “pickup_date” field in trip_data. This creates a one-to-many relationship from the dimension to the fact table.
Repeat this process for the other dimensions:
- Drag location_id from pickup_locations to pickup_location_id in trip_data
- Drag location_id from dropoff_locations to dropoff_location_id in trip_data
- Drag taxi_type_id from taxi_types to taxi_type_id in trip_data
And just like that, you’ve got a proper star schema set up.
Making the Model User-Friendly
Here’s the thing about semantic modeling: it’s all about making your data easy to use. That means renaming tables, hiding unnecessary columns, and generally cleaning things up for your report consumers.
Renaming Tables
Technical table names like “dim_dates” aren’t very friendly for business users. Let’s rename them to something cleaner:
- dim_dates → Dates
- pickup_locations → Pickup Locations
- dropoff_locations → Dropoff Locations
- taxi_types → Taxi Types
- trip_data → Trip Data
To rename a table, click on the “Data” view, find the table in the list, click the three dots next to it, and select “Rename.” Easy.
Hiding Columns
Now let’s hide the columns that report users don’t need to see. This typically includes:
- Primary keys in dimension tables (like location_id, taxi_type_id)
- Foreign keys in the fact table
- Numeric columns in the fact table that will be used in measures
For the date dimension, I’m actually keeping the date column visible because users will want to filter by date. But for the other dimensions, I’ll hide the ID columns.
In the fact table, I’m hiding pretty much everything. All the foreign keys? Hidden. All the numeric fields like trip_distance, fare_amount, and passenger_count? Hidden. Why? Because we’re going to create explicit DAX measures for aggregations. Users shouldn’t be dragging raw columns onto their reports—they should be using the measures we define.
Mind you, you can select multiple columns by shift-clicking or control-clicking, then hide them all at once. Though I found that control-click didn’t work in the web interface, so shift-click to select ranges works better.
Creating DAX Measures
Now for the fun part: creating measures to analyze our data. We’ll create a few basic measures for trip distance, fare amount, and passenger count.
Creating Your First Measure
You can create a measure by clicking the “New measure” button at the top. But here’s a gotcha: that button doesn’t know which table you want the measure in, so it might create it in the wrong place. I accidentally created a measure in the Dates table when I wanted it in Trip Data.
The better way is to right-click on the table where you want the measure (Trip Data in this case) and select “New measure.” That way it goes straight to the right table.
Here are the measures I created:
Trip Distance in Miles =
SUM(trip_data[trip_distance])
Passenger Count =
SUM(trip_data[passenger_count])
Fare Amount =
SUM(trip_data[fare_amount])
If you accidentally create a measure in the wrong table, you can move it by selecting the measure in the model view, then changing the “Home table” property in the properties pane. In Power BI Desktop there’s a dedicated button for this, but in the web interface you need to use the properties pane.
Creating Derived Measures
Once you have base measures, you can create derived measures that use them. For example:
Passenger Miles =
[Passenger Count] * [Trip Distance in Miles]
Average Fare per Passenger =
DIVIDE([Fare Amount], [Passenger Count])
Notice that I’m using the DIVIDE function instead of a simple division operator. This is a DAX best practice because DIVIDE handles division by zero gracefully—it returns blank instead of an error.

Creating a Report from Your Semantic Model
Now that your semantic model is set up with relationships and measures, you’re ready to create reports. Navigate back to your workspace and find the semantic model you just created (Taxi Analysis in my case).
Click the three dots next to the semantic model and select “Create report.” This opens Power BI’s web-based reporting interface where you can start building visualizations.
I’m not going to walk through creating reports in this post—that’s a topic for another day. But the point is, you now have a complete workflow from lakehouse to semantic model to report, all without ever opening Power BI Desktop.
A Note on Tabular Editor
In practice, if I were working on a real project with dozens or hundreds of measures, I’d probably use Power BI Desktop along with Tabular Editor to bulk-create measures efficiently. But for quick models or when you don’t have access to Desktop, the web interface works surprisingly well.
Maybe I’ll cover Tabular Editor in a future video. Let me know in the comments if that’s something you’d like to see!
What You’ve Learned Today
Let’s recap what we covered:
- How to create a Power BI semantic model directly from a Fabric lakehouse
- How to set up relationships using drag-and-drop
- How to rename tables and hide columns to make the model user-friendly
- How to create DAX measures (both base measures and derived measures)
- How to jump straight into report creation from your semantic model
The whole process is really intuitive and works entirely in the browser. This is great news for MacBook users, people with locked-down corporate laptops, or anyone who just prefers working in the web. You don’t need Power BI Desktop for most things anymore, which honestly is pretty amazing.
Are you creating semantic models in the Fabric portal, or are you still using Power BI Desktop? What do you think of the web-based experience? Let me know in the comments below!