You are almost on the mark. The last line of the error tooltip gives a hint: a String switch expects a String expression, but was given a Boolean one. The cases represent literal values the expression may take, and/or a default case to specify what to do if no case is a match.
However, you have here two variables that are more or less Boolean, the strings that may be “Yes” or “No”. You can now do two things:
Change this part of the workflow to have two Decisions, one for Money = "Yes" and one for Response = "Yes":
.
You could also make the variables Booleans and use them directly as the expression;
Use the Switch with an expression like Money & Response and case values like YesYes, YesNo. In this case, though, there is no easy way to catch just “No Money”, you must either cover this as the default case or redirect both NoYes and NoNo to the same sequence.
I would personally prefer the first option and use Booleans if these variables may take only two values. This most clearly demonstrates your intent of having one path for “No Money”, regardless of Response, and leaves the smallest margin for bugs.
Edit: In fact my example workflow displays a potential issue with the use of Strings for Boolean values: if Money = "Yes" is false, this doesn’t imply that Money = "No". This implication does hold for Boolean variables as they can only be True or False.
I thought Boolean’s were true/false results - ‘Money’ and ‘Response’ are strings which is why I was confused by the error.
Decisions did cross my mind but I figured the Switch activity was cleaner. The screenshot posted was a smaller version of my process to test with - both variables are defined earlier on so ‘Money = No’ won’t cause any issues.
I’ll go with your first option and refrain from using Strings instead of Booleans, lesson learnt!
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.
The two variables are indeed strings, but when you form expressions like