Forum Academy Marketplace Showcase Pricing Features

Separate workflows for conditional element appearances?

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.

We’ll think about it. It can lead to a bit of a complex interface, but that’s an interesting idea.