Forum Discussion
Power BI DirectQuery: Unable to change Server parameter in Service (works in Import mode)
I’m looking for clarification on Power BI Service parameter behavior when using DirectQuery vs Import mode, in a setup that involves StrongDM (SDM) and an On-Premises Data Gateway.
Environment
Power BI Desktop
Power BI Service / Microsoft Fabric
On-Premises Data Gateway (Enterprise mode)
SQL Server (on-prem)
StrongDM (SDM) used as the secure access layer
Semantic model uses Power Query parameters for Server and Database
StrongDM Context
Developers connect locally using a StrongDM-specific server alias / suffix
Power BI Service + Gateway must connect using the real SQL Server hostname
Because of this, we use Power Query parameters to control the server value
Example:
Desktop (via SDM):
server-with-sdm-aliasService / Gateway:
real-sql-server-hostname
What Works (Import Mode)
Created Power Query parameters:
Server
DB
Used them in queries:
Sql.Database(Server, DB)Built the semantic model in Import mode
Published to Power BI Service
In Semantic model → Parameters (Service):
I can edit the Server parameter
For example, remove the SDM-specific part of the server string
Mapped the dataset to the On-Premises Gateway
This flow works as expected (refresh currently fails only due to a known SQL certificate trust issue, which is unrelated).
What Does NOT Work (DirectQuery Mode)
When I repeat the same steps using DirectQuery instead of Import:
After publishing the semantic model
In Semantic model → Parameters (Service):
The Server parameter is not editable
I cannot modify or remove the SDM-specific part of the server string
As a result, I cannot adjust the connection post-publish or rebind it cleanly to the Gateway
Questions
Is it by design that connection-defining parameters (Server / Database) cannot be edited in Power BI Service for DirectQuery datasets?
Is the correct understanding that:
Import mode → parameters can be changed in Service
DirectQuery mode → server/database are locked at publish time?
In StrongDM-based architectures, is the only supported DirectQuery approach to ensure the final server name is already correct in Desktop before publishing, with no Service-side changes?
Are there any recommended patterns from Microsoft for DirectQuery + Gateway + SDM-style access layers, or is Import mode the intended approach in these cases?
Why This Matters
This distinction is important in enterprise environments where:
StrongDM or similar zero-trust access layers are used
Gateway is mandatory
Desktop and Service require different server identifiers
Parameters are needed to bridge those environments
Clear confirmation on whether this is a design limitation or expected behavior would be very helpful.
Thanks in advance for any clarification.
Hi Bhargava_B ,
Thanks for reaching out to the Microsoft fabric community forum.Thank you for clearly outlining the scenario. The behavior you are observing is expected and is not specific to StrongDM or your gateway configuration. In Power BI, Import and DirectQuery handle connections differently, which directly impacts how parameters function in the Service.
With Import mode, parameters like server and database are only evaluated during data refresh. Since the model isn't querying the source live, the Service allows you to change these values after publishing; the new values are applied at the next dataset refresh through the gateway. This explains why modifying the server name in the Service works as expected for Import models.
In contrast, DirectQuery keeps the semantic model tightly linked to the data source set at publish time, and all user queries are sent live through the gateway. As a result, Power BI does not permit editing server or database parameters in the Service after publishing, since these are part of the connection identity and must match a gateway-configured data source. Allowing changes in the Service would disrupt query routing and compromise gateway security, so these parameters are intentionally locked.
Therefore, with DirectQuery, the final server name resolvable by the gateway must be correct in Power BI Desktop before publishing. If different hostnames are needed between Desktop and the Service, there is no supported way to change them post-publish. Common approaches include standardizing on a single hostname for both environments or maintaining separate models per environment. When this is not possible, Import mode is generally preferred, as it supports environment-specific parameter changes in the Service.
In summary, this is by design, and your understanding of Import versus DirectQuery behavior is accurate. DirectQuery requires connection details to be finalized prior to publishing, which is important when working with zero trust access layers and gateways. Your observations align with how Power BI is intended to function.
Thank you.
4 Replies
Hii Bhargava_B
In DirectQuery, the semantic model must remain tightly bound to the original data source and gateway mapping to guarantee query consistency and security. Unlike Import mode where parameters are resolved during refresh DirectQuery connections are evaluated at query time, so the server name must already match the gateway configuration. As a result, server parameters can be edited in Desktop but are locked in the Service once published.
Import mode → server/database parameters can be changed post-publish
DirectQuery mode → server/database are fixed at publish time
Hi Bhargava_B ,
Thanks for reaching out to the Microsoft fabric community forum.Thank you for clearly outlining the scenario. The behavior you are observing is expected and is not specific to StrongDM or your gateway configuration. In Power BI, Import and DirectQuery handle connections differently, which directly impacts how parameters function in the Service.
With Import mode, parameters like server and database are only evaluated during data refresh. Since the model isn't querying the source live, the Service allows you to change these values after publishing; the new values are applied at the next dataset refresh through the gateway. This explains why modifying the server name in the Service works as expected for Import models.
In contrast, DirectQuery keeps the semantic model tightly linked to the data source set at publish time, and all user queries are sent live through the gateway. As a result, Power BI does not permit editing server or database parameters in the Service after publishing, since these are part of the connection identity and must match a gateway-configured data source. Allowing changes in the Service would disrupt query routing and compromise gateway security, so these parameters are intentionally locked.
Therefore, with DirectQuery, the final server name resolvable by the gateway must be correct in Power BI Desktop before publishing. If different hostnames are needed between Desktop and the Service, there is no supported way to change them post-publish. Common approaches include standardizing on a single hostname for both environments or maintaining separate models per environment. When this is not possible, Import mode is generally preferred, as it supports environment-specific parameter changes in the Service.
In summary, this is by design, and your understanding of Import versus DirectQuery behavior is accurate. DirectQuery requires connection details to be finalized prior to publishing, which is important when working with zero trust access layers and gateways. Your observations align with how Power BI is intended to function.
Thank you.Hi Bhargava_B ,
I wanted to follow up and see if you had a chance to review the information shared. If you have any further questions or need additional assistance, feel free to reach out.
Thank you.
