Improve condition builder in Fusion

[#1]

Description -

The condition builder in Fusion supports a very simplistic Boolean logic, allowing simple expressions such as (A && B) || (C && D).  This is functional under many circumstances, though forces a lot of duplication of checks on the UI side.

The following is an example of a condition that would be problematic:

ID = "foo" && (Error 1 = true || Error 2 = true || Error 3 = true || Error 4 = true)

In the existing condition builder, it results in something that looks like this:

(ID = "foo" && Error 1 = true) || (ID = "foo" && Error 2 = true) || (ID = "foo" && Error 3 = true) || (ID = "foo" && Error 4 = true)

If we have to change the value of "foo", this creates a risk whereby a human may miss all instances of "foo".  (This risk increases with increasingly complex conditions.)

The ask is to improve the condition builder to allow for full Boolean logic.  We have a similar version built into our own product, and I'm attaching an example of what that type of UI might look like as a concept to showcase how to think about the proposal.

Why is this feature important to you -

We are currently having to implement such complex conditions through either (1) duplicating values/checks or (2) a series of Router and Set Variable modules that perform the evaluation using edge filters between modules.  Either way, it's a cost/risk introduced due to a UI that is limited in its current form.

How would you like the feature to work -

Anywhere that conditions are allowed (event watchers, edge filters, etc.), use the same enhanced UI mechanism.  Allow a user to create a Boolean expression similar to how a developer would do it -- through nesting and grouping of logical operators.  If the backend needs to translate that down to a simpler form for evaluation, that can be transformed internally.

Current Behaviour -

Described above in the Description.

Screen Shot 2023-07-13 at 3.28.00 PM.png ‏834 KB

[#2]

Not only does Fusion work like this but all the report filters have this problem as well. This is a great example that really illustrates the core problem.

In fact, I would say the title of this Idea Post should be just "Improve Condition Builder"

[#3]

If this is the condition logic expressed in its simplest terms:
ID = "foo" && (Error 1 = true || Error 2 = true || Error 3 = true || Error 4 = true)

Then I agree that this expression is inefficient to build and maintain:
(ID = "foo" && Error 1 = true) || (ID = "foo" && Error 2 = true) || (ID = "foo" && Error 3 = true) || (ID = "foo" && Error 4 = true)

My recommendation in that example would be to use an array filter to consolidate multiple expressions into one:
(ID = "foo") && ({{add(emptyarray; "Error 1"; "Error 2"; "Error 3"; "Error 4")}} contains "true")

This would allow you to update just the value of "foo" and not miss any other occurrences in the expression; or bulk change the value of all errors to "false" in one place.

It's most commonly useful when you want to filter against a set of possible statuses and don't want to create separate conditions for each status value.

[#4]

William,

Thank you, and I understand that for that specific condition, such a trick might work.  But it (1) requires familiarity with data structure trickery and (2) is fairly constrained to the types of expressions where you're comparing everything to one thing like that.  If instead of true I were to compare against various string values, for example, such a thing would not work and we'd be back at that point.  So please take the idea suggestion in the generic form in which it was intended.  (PMs always ask for the "use case" -- so that's what I'm providing here.)

Cheers,

Chris

[#5]

It appears that Workfront's backend was poorly designed during its early development, thus developers are unable to address such issues up until now.