I just came across this issue as well and perhaps identified where the issue is.
@v-yamao-msft used a substring during testing, and that is part of the key here. The real issue is that when you create a trigger input and select it to be a text, or a selection of a text you expect this to be a string. That is not the case when using the trigger in switch it seems, providing a somewhat non-descript error message. This seems to be because switch is setting the datatype on the disregarding information from the trigger body:
"text_1": {
"title": "Master",
"type": "string", <----
"x-ms-dynamically-added": true,
"description": "Select master year",
"x-ms-content-hint": "TEXT",
"enum": [
"2020",
"2021"
]
}
if I supply the direct, or even indirect value from the trigger (button) it does not work, but if i replace this with a text string at design time its no issue. (Images show using compose but these have been tested both directly and indirectly with compose.)
manually input a value to the compose used in switch
manually input a value to the compose used in switch
input from a button text field fails
input from a button text field fails
I Thought perhaps that the solution would be to adding a string() expression on what is expected to be a string in the first place as the field is actually named a text field regardless if you are using it in a dropdown or selection.
workaround with using string()
But it seems that the magic is happening in the switch step where it seems to set the data type from its content at input, while its cases are handled as strings. I then found that adding a non numeric value to the end of the comparison to the switch input will make it interpret it as a string instead of a number datatype. you will also have to add this non-number character at the end of the cases as well.
This seems to be a workaround to the issue.
force string type of input
