I find myself overloading the appearance and behavior of control elements a lot based on the DB state.
For example, the same button may have 3+ functions and appearances based on where the user is.
Currently this requires creating two sets of conditions: one to define the element’s appearance, another to define a conditional workflow that is triggered by interaction with this appearance. The two sets are independently defined, so they may or may not overlap.
However, in a fairly common case when the input element’s appearance and the input element’s function are 1:1 related, I end up duplicating the same set of conditions twice. This is lengthy and error-prone because every change needs to be entered two times. It would be much cleaner if there would be a method to define a “sub-workflow” from within the conditional appearance that leads directly to desired behavior.