Not a problem. But I seem to have missed the line in your first post where you mention GenericValue. There is an even more interesting lesson in that! The two variables are indeed strings, but when you form expressions like
Money = "Yes" And Response = "Yes", these evaluate to Boolean values, which can be stored in GenericValues. A switch with a GenericValue is a very interesting case, as GenericValues can also store strings and numerical data. I’m fairly sure what happens in your example workflow is the following:
- The switch expression evaluates to True (Boolean);
- The case values are instead taken to be String values;
- Therefore, no matching case is found. There is no default case either, so execution can’t continue.
The catch here is that the cases of a switch must be, in technical terms, literal values. Without going into too much detail, this means that they can’t be or contain variables, only fixed values of the same type as the TypeArgument, like the integer
1000 or the string (without quotes!)
Hello World. The fact that text without quotes represents a string in this context is unfortunate and confusing, but this is how it works.
This makes another good reason to be explicit about your intent when programming (which designing workflows is), in this case by specifying a precise TypeArgument. Your intuitive decision of setting the TypeArgument to String was entirely appropriate. Studio can then prevent you from accidentally providing the wrong type, although the error messages are usually terse and hard to interpret. You will probably find the “Strict On” error more often, this is a setting (which you can’t change) that in fact helps you prevent getting in this situation, by disabling in this case the conversion of Boolean to the string “True” or “False” that would otherwise automatically occur. Since everything has a string representation, it’s not hard to see how that could cause unexpected behaviour.
With all of that said, it all depends on the use case. Another workflow designer may have read a value from somewhere, like a triple choice answer on some form, that may be “Yes”, “No” or “Don’t Know”. In this case a string switch is more suitable, with these three cases plus the default case for robustness, where you can for example log this unexpected value while allowing the workflow to proceed.