Why "Keyword not supported: variables" Breaks Dataflow Gen2 — Even After You Remove the Gateway

You set up a Dataflow Gen2 in Microsoft Fabric. Source is straightforward — maybe SQL Server through an on-premises data gateway, maybe just Enter Data for testing. Destination is a Fabric Warehouse. You configure the gateway connection, hit evaluate in the Power Query editor, and get this:

Keyword not supported: variables. Parameter name: keyword.

Fair enough. You suspect the gateway binding, so you remove it. Switch to a cloud-only connection. Re-select the Warehouse destination. Evaluate again. Same error.

This is the part that costs people hours. The error does not originate from the active connection — it originates from metadata that Fabric persisted when you first bound the gateway. The Dataflow Gen2 mashup document retains connection string fragments from every connection it has touched. When the gateway path injects a variables parameter into the connection string — likely related to Fabric's Variable Library integration plumbing — that parameter gets baked into the document. The ADO.NET SQL client used by the mashup engine does not recognize variables as a valid connection string keyword, so it throws an ArgumentException before the query even reaches the data source.

The error fires during evaluation in the Power Query editor, not during scheduled refresh. This means you cannot even author your transformation logic. The dataflow is effectively bricked at design time.

Dataflow Gen2 stores its transformation logic in a mashup document — an M-language script bundled with connection metadata, credential references, and destination bindings. When you configure a data destination, Fabric writes the connection parameters into this document. When you select an on-premises data gateway for a source, Fabric routes the connection through the gateway and records the gateway-specific connection string.

Here is where things go wrong. Fabric Warehouse destinations use a TDS endpoint (TCP port 1433) for both reading staged data and writing output. When the mashup engine assembles the connection string for that TDS endpoint, it can include internal parameters that the gateway path expects — including a variables parameter that maps to Fabric's Variable Library resolution layer. This parameter is meaningful to Fabric's internal orchestration but is not a standard ADO.NET SqlConnection keyword.

The ADO.NET SqlConnectionStringBuilder validates every keyword against a fixed allowlist. The word variables is not on it. Result: System.ArgumentException: Keyword not supported: 'variables'. Parameter name: keyword.

Critically, removing the gateway connection from the dataflow UI does not strip this parameter from the stored mashup document. The metadata layer and the UI layer are not synchronized on removal. You can confirm this by exporting the dataflow definition (if using CI/CD mode) and inspecting the mashup.pq file — the connection string fragment containing variables will still be present even after the gateway is deselected in the editor.

This is a metadata binding bug, not a user configuration error. It has been reported on Fabric capacity SKUs as small as F8 and across multiple client versions.

Path 1: Create a new Dataflow Gen2. This is the most reliable fix. Create a fresh dataflow in the same workspace. Rebuild your M queries — or copy them from the Advanced Editor of the broken dataflow. Configure the Warehouse destination using only cloud credentials. Do not touch the gateway connection at any point during setup. The new mashup document will not contain the poisoned variables keyword.

Path 2: Edit the mashup.pq directly via CI/CD export. If your Dataflow Gen2 is deployed through Fabric's CI/CD pipeline (git integration), you can access the mashup.pq file in your repository. Search for the variables keyword in the connection string metadata section. Remove it. Commit and redeploy. This preserves your existing query logic without manual reconstruction, but it requires that you have git integration enabled on the workspace.

Path 3: Recreate in a new workspace as a diagnostic step. If paths 1 and 2 both fail, the issue may be workspace-level. Some users have reported that connection metadata can be cached at the workspace scope, not just the dataflow scope. Creating the dataflow in a clean workspace and then migrating it back after successful evaluation confirms whether workspace-level metadata contamination is involved.

What does not work: removing and re-adding the Warehouse destination in the existing dataflow. The mashup document retains the connection string fragment. Re-selecting the destination does not trigger a full metadata rebuild — it merges new settings with existing ones.

Also ineffective: changing the gateway version or reinstalling the on-premises data gateway. The problem is not in the gateway software. It is in the Fabric-side mashup document that was generated during the initial gateway binding.

Fabric's Variable Library feature, generally available in Dataflow Gen2 with CI/CD, adds another dimension. Variable Libraries let you externalize configuration values — connection strings, workspace IDs, environment flags — into a shared Fabric item. Dataflows reference these values using Variable.Value() or Variable.ValueOrDefault() in M code.

The variables keyword that poisons the connection string appears to be related to this infrastructure. When a dataflow is configured to resolve Variable Library references, Fabric's orchestration layer appends variable resolution metadata to the connection string. In cloud-only scenarios, this metadata is handled internally and never reaches the ADO.NET parser. But when a gateway is involved, the connection string passes through a different code path — one that exposes the raw variables parameter to the SQL client.

This means the error is more likely to surface if you have a Variable Library in the same workspace, even if you are not actively referencing variables in your dataflow. The presence of the library can trigger Fabric to inject the parameter preemptively.

To reduce exposure: if you must use an on-premises data gateway with Dataflow Gen2, avoid having Variable Libraries in the same workspace. Keep gateway-dependent dataflows in workspaces without Variable Library items. If you need both, use Fabric Pipelines to chain a gateway-sourced dataflow (in one workspace) with a variable-driven dataflow (in another).

Only basic variable types are supported — boolean, datetime, guid, integer, number, and string. Attempting to pass complex types through Variable Libraries can produce a separate class of errors (error code 10418), which compounds debugging if you are already dealing with the variables keyword issue.

A related but distinct failure mode involves port 1433 access from the on-premises data gateway to Fabric's staging Lakehouse. When your dataflow has multiple queries that reference each other, the mashup engine reads intermediate results from the staging Lakehouse using the TDS protocol over port 1433. If the gateway server's firewall blocks that outbound traffic, you get a different error:

MashupException.Error: Microsoft SQL: A network-related or instance-specific error
occurred while establishing a connection to SQL Server.

This error can appear alongside or instead of the variables keyword error, depending on which connection string parameter the parser hits first. If the firewall is blocking port 1433, the ADO.NET client may fail on the network layer before it ever validates the keyword list — meaning the variables bug is hidden behind a network error.

To isolate the two issues, ensure these endpoints are reachable from the gateway server on TCP 1433: .datawarehouse.pbidedicated.windows.net, .datawarehouse.fabric.microsoft.com, and *.dfs.fabric.microsoft.com. You can scope this further by navigating to your workspace, finding the DataflowsStagingLakehouse item, selecting View Details, and copying the SQL connection string endpoint.

Once the firewall is confirmed open, re-evaluate the dataflow. If the variables keyword error reappears, you know the problem is metadata contamination, not network access. Fix the metadata using one of the three paths above.

For dataflows that do not reference other queries, you can also disable staging or combine queries into a single step as a temporary workaround. This avoids the TDS read path entirely, eliminating the port 1433 dependency — though it may degrade performance for complex transformations.

The worst version of this bug is the one you do not notice. You create a dataflow, hit the gateway issue, switch to cloud credentials, and assume the problem is fixed because the UI no longer shows a gateway reference. The dataflow sits in your workspace, failing silently on every scheduled refresh, while downstream reports serve yesterday's data.

Fabric's built-in monitoring shows refresh failures, but only if someone checks. The refresh history page buries the actual error message behind multiple clicks — Refresh History, then Failed, then Activity Details, then Error Message. Most teams do not have someone watching that page at 4 AM.

MetricSign monitors Fabric Pipeline and dataflow refresh status continuously. When a Dataflow Gen2 refresh fails, MetricSign surfaces the error message — including connection string keyword errors — with root cause context that identifies whether the failure is network, credential, or metadata related. Instead of a generic "refresh failed" alert, your on-call engineer sees that the mashup document contains an unsupported keyword, which points directly to the metadata contamination issue rather than sending them down a firewall troubleshooting rabbit hole.

The connection string keyword error is deterministic — it will fail every time until the metadata is fixed. That makes it a good candidate for automated detection: if the same dataflow fails with the same error on consecutive refreshes, the fix is structural, not transient. Grouping consecutive identical failures into a single incident prevents alert fatigue while keeping the issue visible until someone applies one of the three resolution paths.