I would like to use a decision table to determine a particular display configured as an expression. If an object is of type A and Status B, then display rule!AB. The configured expression would not take in any inputs and is only for display purposes.
Discussion posts and replies are publicly visible
This is super ghetto but you could always wrap the decision in an expression rule and direct the expression rule to call different [expressionable] outcomes based on a particular plaintext output from the decision.
Though at that rate, it seems hardly worth it to even bother with the decision rule anymore - which is why I've ended up hardly ever using them.
Kind of. The use case is perfect. I don't want to create some giant if statement, but it looks like that's the only option.
Your decision could just return integers 1 - N, then an expression rule wraps it in a choose() statement, to avoid a thousand nested if() levels.
But yes I agree, decisions will only ever be actually useful for any use cases more complicated than very simple ones and/or demos, when they're more expressionable in the inputs and/or in the outputs.
Mike Schmitt said:Though at that rate, it seems hardly worth it to even bother with the decision rule anymore - which is why I've ended up hardly ever using them.
Just wanted to chime in to agree with this - without expressionable outputs for decision rules, I haven't been able to find any use cases to actually implement one in production, in my environment. This might be a case for a new "Feature Request" thread..
Somewhat recently I did come upon a particular use case - something that assigns different arbitrary text output values to various arbitrary combinations of input status IDs (in some cases keying off a main status id and a substatus id, and in other cases just the main status id). That works well, and the same thing in an expression rule would've been, while not very hard, a painful amount of if() handling, etc.
However, so far this has been the only time I've used one (and i had to be OK with the hardcoding of values involved, which I just kinda had to overlook in this case), -- but all other occasions I've investigated the possibility I've found that they just don't cut it.