Forum Discussion
Helper IUpdating a Semantic Model to use a different Workspace
I had a call with Microsoft and resolved this issue.
Open Deployment Pipeline’s “Rules”
Chose “Data source rules”
“Server”
Navigate to the Workspace you want the Semantic Model’s data to come from
Click the three dots against the Lakehouse you need to use > Settings
Copy the SQL analytics endpoint > SQL connection string into the “Server” section of the Data source rule
“Database”
Navigate to the Workspace you want the Semantic Model’s data to come from
Click into the SQL analytics endpoint of the Lakehouse you need to use
Copy the GUID after mirroredwarehouse in the URL into the “Database” section of the Data source rule, i.e. the "Artifact ID" in a URL that looks like this https://app.fabric.microsoft.com/groups/<Workspace ID>/<Artifact type>/<Artifact ID>/
That GUID in the "database" field isn’t the actual database name you’d use to connect via SQL; it’s an internal Fabric-assigned ID for the semantic model’s “database” object within the SQL endpoint. Even if multiple semantic models point to the same Lakehouse, each model has its own internal metadata, so the GUID differs across models.
Think of it as the semantic model’s “wrapper” ID inside the endpoint — it tells Fabric which model’s metadata and measures to expose, while the server string always points to the same Lakehouse SQL endpoint.
So when working with Direct Lake, you only need the server to query the lakehouse. The database GUID is mostly for internal tracking and API references.
Helper ISo is there a way for me to update those strings to change it such that a semantic model created in dev and pointing to dev's lakehouse points to prod's lakehouse when it is published there?
Basically I want to develop my semantic model in dev using local data, build reports on top of it, and then deploy the data plus model plus reports to prod, with the only difference being that the data is coming from prod's lakehouse at that point.
Yes — that’s exactly the pattern Fabric is designed for, but you don’t update the GUIDs manually. Instead, the standard approach is:
1. Use the same semantic model definition in dev and prod, but configure the Gateway & Cloud connections in each environment to point to the respective Lakehouse.
2. When you promote or copy a semantic model (via APIs, Semantic Link Labs, or workspace “Copy” features), you can preserve the model’s metadata and DAX logic. After that, you just update the data connection in prod to point to the production Lakehouse.
3. The GUID you see in dev is automatically regenerated in prod, so each environment’s semantic model has its own internal ID — you don’t need to—and shouldn’t—try to set it manually.
In short: develop against dev Lakehouse → copy model to prod → update Gateway & Cloud connection to prod Lakehouse → reports continue working.
- dolphinantonym
Thank you.
What is involved in the process of "configure the Gateway & Cloud connections in each environment"? I'm not sure what the gateway and cloud connections are, and I don't remember setting up any of those things (not explicitly, at least) when creating things in dev, so I'm not sure which elements I need to change in prod or how.
In Fabric / Power BI, the Gateway & Cloud connections are basically the configuration that tells the semantic model where to get its data in each environment. In Dev, you might not have explicitly set anything because it can auto-connect to your Lakehouse, but in Prod you’ll need to make sure it points to the right endpoint.
The process usually involves:
1. Go to the semantic model in Fabric → click Settings → Gateway & Cloud connections.
2. You’ll see the list of data sources the model uses (for Direct Lake, this is usually the SQL endpoint of your Lakehouse).
3. Update the connection to point to your Prod Lakehouse endpoint. For cloud sources, this might involve selecting or adding a cloud connection or credentials that have access to Prod.
4. Save changes — the semantic model now queries Prod data, while keeping all your measures, calculated tables, and DAX logic intact.
Basically, the connection settings are just pointers to the right data source, and that’s the only thing you need to change when moving from Dev → Prod.