Forum Academy Marketplace Showcase Pricing Features

A new element for branched logic or intermediate values

I’ve started using invisible elements to manage more complicated logic than the expression builder can handle.

Example: if multiple expressions need to work with the same list, create an invisible repeating group and set its data to that search so that its value is the list. Then all of the other expressions can reference that repeating group’s value directly instead of having to rebuild the search each time.

Example: if a text field needs to have different combinations of messages based on different conditions, create invisible input elements to handle each logical branch. The input element has a value that can be set and changed using its conditions. If you need more than one branch, just use a string of invisible input elements referencing each other’s value.

Since this stuff is built out of existing elements it stands to reason that we should be able to build a new element to handle this “caching” of intermediate data.

How would that be different than states and workflows? i.e. running a workflow and setting the result as a state.

Are you doing this for a native app?

  1. expressions update automatically; workflows have to be run
  2. expressions are free; workflows count against you

Only workflows that persist a change in the database count against the workflow count (AFAIK).

So something like a show/hide wouldn’t count? Is that documented somewhere?