Parameter with dropdown: how to update values?

[reynsnivea]

Hi,

I am thinking about using the fixed list type parameter so that users can select the allowed values for a specific parameter. This parameter will be a parameter that appears in multiple morph-files.

What if we want to update the values of that parameter for some reason, then we would have to update all the morph files in which the parameter appears?

Now I use the text parameter but that is prone to errors.

Any thoughts about the best set-up ?

Thanks
Nikolaas

[dgudkov]

Using a dynamic list of permitted values for a fixed-list parameter isn’t currently possible.

To a certain extent, it can be done with the Data Catalog, where one Catalog item would return a list of options (it can be generated dynamically), and selecting one of the options would trigger another workflow with the selected option. However, this only works in Desktop, currently.

[ithiessen]

Is it possible to add an option to retrieve the values for a "Fixed list" or "Multiple choice" by calling a project/module result table or retrieve a data catalog asset? This would help to replace Alteryx apps that support dynamic parameter values.

[dgudkov]

Dynamic parameter values will be managed via the "User input" action.

@ithiessen

Is it possible to add an option to retrieve the values for a "Fixed list" or "Multiple choice" by calling a project/module result table or retrieve a data catalog asset?

I was thinking about this option, but while it looks simple on the surface, it can quickly become complicated because the other module can theoretically also have parameters that require another module, and so on.

[ithiessen]

Thank you, @dgudkov, for your response and pointing to the roadmap.

"Compilcated" is ok to me, as long as the developer can determine the output

@dgudkov

Dynamic parameter values will be managed via the "User input" action.

So instead of prompting for parameters in the beginning of a run, with "User input" we will have the chance to prompt for (selected) parameters that might get their values from one or more actions before the "user input" action, correct? Sounds like a good alternative.

My POV: The risk that I see is that if you need a "dynamic" parameter (definition) several times, you can't develop it once and use it everywhere like a custom action (other project). You can copy the actions and modify it, but not capsule it. That approach would not be favorable in a governed enterprise context.

[dgudkov]

@ithiessen

So instead of prompting for parameters in the beginning of a run, with "User input" we will have the chance to prompt for (selected) parameters that might get their values from one or more actions before the "user input" action, correct? Sounds like a good alternative.

Yes, that's correct.

@ithiessen

My POV: The risk that I see is that if you need a "dynamic" parameter (definition) several times, you can't develop it once and use it everywhere like a custom action (other project). You can copy the actions and modify it, but not capsule it. That approach would not be favorable in a governed enterprise context.

That's a valid concern. It should be possible to encapsulate obtaining lists of values dynamically in the form of Catalog assets or Server-hosted datasets.