Sometimes I have a situation like this: a bunch of inputs I need the user to fill out before they can click a button that runs a workflow, but:
The workflow doesn’t actually use those fields, so “This element should not be empty” doesn’t work, and
It’s annoying to have a condition on a workflow for like 10 different fields “Only when Field1 is not empty and Field2 is not empty…” (or a similar conditional on the button).
So, is there any simpler way to deal with this situation? Thanks!
I kind of don’t think that there is. A couple of potential workarounds (warning not a tutorial or well-thought-out suggestions):
One idea: Build a list of conditions (boolean / yes/no values) of the correct size. Use each item in that list to represent the “is empty” state of each input. Basically, this moves the pain from a big long conditional statement to individual workflows (When an input is changed > set the item number in this list representing that input to that input’s “is empty” value.) At least, in this way, you could check all 10 conditions at once. You could either check if that list contains “no” (if there are any “no” values in the list this condition will be true) or do it with a :filter condition.
And actually, the workflow action could probably build the list for you. Basically what you’re trying to do is “count to 10”, right? So I suppose we could instead just have an integer custom state. When any of the inputs goes valid, add 1 to that integer state. When any of the inputs goes invalid, subtract 1 from that state. … The button is only clickable / formatted like everything’s cool when that state is equal to 10.
Second idea: There is no second idea beyond do some JS to find the count of input elements which really doesn’t save any time or hassle. I think the workflow increment/decrement with a number is probably the best solution that’s at least somewhat preferable to wonky multi-AND conditional expressions.
(Idea: what would be nice is if elements in a group could bubble up their validity to their containing group. The natural way for this to work is that the group would inherit an “is valid” property. However, it turns out that group’s with a type [i.e., they have a data source] already do have an “is valid” property.
At one time (and again even as I was writing this answer) I had the thought that perhaps a group’s “is valid” state represented the state that all inputs within it are valid. Unfortunately, this is not the case. A group’s “is valid” state is a property only of groups with a type and it seems to indicate whether the value of the group’s data source is valid. This seems like a waste as isn’t that the same thing as checking if the group’s data source is not empty? I could be wrong about what a typed group’s “is valid” state represents as this seems to be undocumented in the reference.)
