Please make it possible to design it as one specific value goes one way and ‘the rest’ will go the other way:
then you don't need to design every enumurated value
And if you use $Obj/enumvalue = ENUM.Enumvalue in the decision block?
Then True would be the one value, and false would be all other values
Only difference is that the arrow shows 'True' and you should give the decision block a fitting caption
Would add that it might be beneficial to have an explicit None/Empty always defined as opposed to being assumed as part of the "rest" to avoid obvious pitfalls during development, as most of the time this would be redirected off to an error capture / handle anyway.
So would add one additional output path to Eline's picture to accommodate an explicit "Empty" path.
I am really hoping this is going to appear on the roadmap soon. Been doing a lot of enum decisions and it is driving me crazy having to add all the pointless lines
This question has been asked several times in the last few years. See:
Can someone merge these Ideas (and the Votes!)?
Just recently, we have been thinking about exactly this in my team!
It's similar to a switch statement in Java
Would love to see this. Here's an example of what it could look like.
Old situation. While these enum-onions are pretty, they're a pain in the behind to make:
A new version could look something like this:
This means way less work when setting up splits based on enumerations (specifically large ones).
Some thought would need to be given to warnings when expanding existing enums though. Right now you get a hard error as you haven't specified the new value in your split yet, which would vanish in the new version, so a warning might be good.