Forum Discussion

FireFighter1017's avatar
FireFighter1017
Advocate III
10 months ago
Solved

Variable.Value() returns error 10418 "The variable ... could not be found"

I have created a variable library in a premium workspace named "Variables_Dataflows".

In this library I have created a variable named "dfFactMroPurchasingDocuments" with value sets for DEV, QA and PROD.

DEV is the active value set for this workspace.

 

The variable is working fine when used in a data pipeline.

But when I try to use it in a dataflow residing in the smae workspace, either Gen1 or Gen2, it complains that it could not find the variable.

 

Here's the M code I used:

let
  Source = Variable.Value("$(/**/Variables_Dataflows/dfFactMroPurchasingDocuments)")
in
  Source

I can't figure out what's wrong with this code.

Anyone can tell me?

  • Hi FireFighter1017 ,

     

    In Dataflow Gen2, the Power Query editor does not resolve Variable Library values at design time, so Variable.Value("$(/**/Library/Variable)") often throws 10418 in the editor even when the variable exists. Variables are resolved at run time. Also, Variable Libraries are only supported in Dataflow Gen2 with CI/CD, not in Dataflow Gen1. See Microsoft’s docs and notes here: Use Fabric variable libraries in Dataflow Gen2 (Preview).

     

    • Use Dataflow Gen2 with CI/CD (not Gen1) and keep the Variable Library in the same workspace as the dataflow. Docs
    • During authoring, call Variable.ValueOrDefault so the editor can evaluate a fallback; at refresh time Fabric will use the real variable value. Docs
    • Make sure your identifier matches this exact format (display names, including spaces):
      $(/**/LibraryName/VariableName)
    • Test by running the dataflow (Publish + Refresh). Don’t rely on the editor preview for variables. Docs

    Example M you can drop in

    // Works in authoring (fallback) and resolves at run time
    let
      TableName =
        Variable.ValueOrDefault(
          "$(/* */*/Variables_Dataflows/dfFactMroPurchasingDocuments)",
          "dfFactMroPurchasingDocuments_DevFallback"   // match the variable's data type
        ),
      Source = SomeConnectorFunction( TableName )
    in
      Source

     

    If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

6 Replies

  • Hi FireFighter1017 ,

     

    In Dataflow Gen2, the Power Query editor does not resolve Variable Library values at design time, so Variable.Value("$(/**/Library/Variable)") often throws 10418 in the editor even when the variable exists. Variables are resolved at run time. Also, Variable Libraries are only supported in Dataflow Gen2 with CI/CD, not in Dataflow Gen1. See Microsoft’s docs and notes here: Use Fabric variable libraries in Dataflow Gen2 (Preview).

     

    • Use Dataflow Gen2 with CI/CD (not Gen1) and keep the Variable Library in the same workspace as the dataflow. Docs
    • During authoring, call Variable.ValueOrDefault so the editor can evaluate a fallback; at refresh time Fabric will use the real variable value. Docs
    • Make sure your identifier matches this exact format (display names, including spaces):
      $(/**/LibraryName/VariableName)
    • Test by running the dataflow (Publish + Refresh). Don’t rely on the editor preview for variables. Docs

    Example M you can drop in

    // Works in authoring (fallback) and resolves at run time
    let
      TableName =
        Variable.ValueOrDefault(
          "$(/* */*/Variables_Dataflows/dfFactMroPurchasingDocuments)",
          "dfFactMroPurchasingDocuments_DevFallback"   // match the variable's data type
        ),
      Source = SomeConnectorFunction( TableName )
    in
      Source

     

    If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

  • Check Variable Scope

    • Ensure the variable is published and accessible to Dataflows.
    • Confirm that the active value set (DEV) is correctly assigned to the workspace.

    2. Use Correct Syntax

    Try simplifying the path:

     

    Source = Variable.Value("Variables_Dataflows/dfFactMroPurchasingDocuments")

     

    Or even:

     

    Source = Variable.Value("dfFactMroPurchasingDocuments")

     

    Sometimes the full path with $(/**/) is not required in Dataflows.

    3. Test with a Static Value

    To isolate the issue, replace the variable call with a hardcoded value:

     

    Source = "DEV"

     

    If this works, the issue is with variable resolution—not the rest of your query.

     4. Check Dataflow Type

    • Gen1 Dataflows have limited support for advanced features.
    • Gen2 Dataflows are more flexible but still evolving.
    • Try recreating the Dataflow in Gen2 and reapplying the variable.

     5. Use Parameters Instead

    If variables fail, consider using Dataflow Parameters as a workaround:

    • Define a parameter in the Dataflow UI.
    • Reference it in your M code:

     

    Source = ParameterName

     

     

     Known Limitations

    According to recent community feedback and Microsoft documentation:

    • Variable.Value() is not yet fully supported in Dataflows, even in Premium workspaces.
    • It works in Data Pipelines, but not consistently in Dataflows, especially when referencing external libraries.

     

     Recommendation

    Until full support is rolled out:

    • Use parameters in Dataflows.
    • Keep using variables in Pipelines.
    • Monitor Microsoft Fabric updates for expanded support.

    • FireFighter1017's avatar
      FireFighter1017
      Advocate III

      Hi anilgavhane ,

       

      The purpose of this is to specificaly stop using parameters in dataset and dataflows that need to reference existing dataflows.  Mainly because it is a PIA to maintain in deployment pipeline rules.

      We are starting to use data pipelines and using variable libraries seems like an obvious choice for future developments.

  • ok tayloramy , that worked !

    That explains why the few sources where I could see this code had more examples using Variable.ValueOrDefault().

    I also just noticed the big red box telling us why we should use Variable.ValueOrDefault() in your 1st link.

     

    I still have tests to do before I can safely assume this is working as expected.

    I'm hoping to be able to replace all parameters for variables and get rid of deployment rules in deployment pipelines.

     

    Am I wrong?

     

    • tayloramy's avatar
      tayloramy
      Super User

      Hi FireFighter1017

       

      There's use cases for both deployment pipeline rules and variable libraries, but I typically lean towards using only variable libraries as you are describing. 

       

      If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution. 

      • FireFighter1017's avatar
        FireFighter1017
        Advocate III

        Hi tayloramy ,

         

        Yeah I guess until Microsoft finally implements variables for both Gen1 Dataflows and Datasets we'll have to continue using deployment rules.

        The funny thing is you can't go through CI/CD with Gen 2 Dataflows without using variables.  They aren't supported for deployment rules.