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>/
Helper IMy model is Direct Lake.
Under Settings > Gateway and cloud connections I see something like this:
SqlServer{"server":"aaaaaaaaa-111111111111.datawarehouse.fabric.microsoft.com","database":"b2-c3-d4"}
I can find the "server" string - it's the SQL endpoint URL for the Lakehouse - but not the "database" one. What does this GUID relate to? When I look at different Semantic Models using the same Lakehouse, they show different values for this string...
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.
- dolphinantonym
So 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.