How can I have conditional parameter value in Azure Workbook?

Question

How can I have conditional parameter value in Azure Workbook?

I want to have one parameter called environment. It has some text values. E.g. it has two values test and production.

Also, I want to have two other parameters: subscription and app_insights.

Now, I want to select the subscription and app_insights values automatically based on the environment parameter value.

So, here is how I am trying to select the test subscription for the subscription parameter when the environment parameter is test:

summarize by subscriptionId
| project subscriptionId=strcat("/subscriptions/", subscriptionId),
selected = case("{environment}" == "test" and subscriptionId == "test subscription id", true, false)

But it seems that the environment parameter does not get substituted for the "{environment}" placeholder. If I remove the "{environment}" == "test" check, then the test subscription gets selected as expected.

How can I use one parameter to decide the value of another parameter? Is there a better way to achieve what I want? Preferably I also want the subscription and app_insights parameters not to be shown to the user of the workbook and prevent them from being edited manually.

Answer 1

Here's an example which illustrates how a parameter can be conditional upon another.

---

Let's say we have a parameter named Environment, of type Options group which gets data from the following JSON:

[
    { "value":"'dev'", "label":"dev", "selected":true },
    { "value":"'prod'", "label":"prod" }
]

then, we can create a secondary parameter which will return a certain list if dev is selected, and a different one if prod is selected. This second parameter is of type Dropdown and is configured to run an Azure resource graph query across all subscriptions.

resources
| extend dev_subs = dynamic([
  "dev-sub1",
  "dev-sub2"
  ])
| extend prod_subs = dynamic([
  "prod-sub1",
  "prod-sub2"
  ])
| extend selection = {Environment}
| extend output = iff(selection == "dev", dev_subs, prod_subs)
| project output
| mv-expand output
| distinct tostring(output)

when dev is selected in the first parameter, the second parameter will show a dropdown with options dev-sub1 and dev-sub2; when prod is selected, the second parameter will show a dropdown with options prod-sub1 and prod-sub2.

Answer 2

Yes, this is 100% supported.

Parameters have to be declared before they are referenced, and then parameters can be referenced left to right, just like code. Order is important in both steps and parameters.

If you open the "Resource Picker" sample in Workbooks in Azure Monitor:

• there's a hidden parameter of which resource type to show that the subscription picker and resource picker depends on
• everything after subscriptions depends on the selected subscriptions, etc.
• the resource picker depends on which resource groups are selected, etc
• the grid below this depends on resource type, subs, and resources selected, etc.

if you look at the exact query for the resources parameter here, its query text is:

Resources
| where type in~({ResourceTypes})
| extend resourceGroupId = strcat('/subscriptions/', subscriptionId, '/resourceGroups/', resourceGroup)
| where resourceGroupId in~({ResourceGroups}) or '*' in~({ResourceGroups})
| order by name asc
| extend Rank = row_number()
| project value = id, label = name, selected = Rank <= 10, group = resourceGroup

Where you can see that the ResourceGroups parameter and the ResourceTypes parameter are both referenced in the query, and replaced at query time. The Subscriptions parameter is selected in the ARG query's subscription field.

If a parameter isn't being replaced in the query, then that parameter doesn't exist before that query (or the parameter is not marked required and has no value, so it gets replaced as an empty string).

while editing a query step, the toolbar in the upper right corner of that step has an item to open up the query with all the parameters replaced in the appropriate view (the Resource Graph Explorer blade, or Logs query blade, or ADX query site, etc) so you can see exactly how the parameters were replaced.