Business rules in a BPM screen

One can define rules in a BPM screen (the Priority documentation does not explain this acronym which I assume means Business Process Management) in the same way that one defines rules in screens. These rules generally allow users (or groups of users) to change the status of a document according to the value of named fields within the document; these rules can also prevent users from changing status.

I came across an interesting example this morning: in the Customer Orders BPM, there is a rule which allows members of a certain group to change the status of an order from 20 to 60 (the statuses themselves are not relevant here) as long as the 'product bundle' field is not CAD. I had to update this rule to prevent them also from changing the status if the 'product bundle' field is not GLASS. Although one can write a rule with three conditions, this can't be done if there are two 'not equal' conditions.

A translation of the rule into simple English would be: allow users of the group 'Engineering' to change the status of the order from 20 to 60 provided that the product bundle is not CAD and the product bundle is not GLASS. Let's test this rule in our mind: if the value of product bundle is 'Jim', then both conditions are true and so the user can change the status. If the value of product bundle is 'CAD', then one condition will be false, meaning that the rule fails and the user cannot change the status. The same thing happens if the product bundle is 'GLASS'. In other words, one can define this kind of rule as long as there are available conditions - unfortunately, versions of Priority below 19 provide exactly three conditions (I saw a demonstration of Priority v19 a year ago and I think that it allowed more than three conditions).

As it happens, the rule had a spare condition so I could have written the rule with two conditions checking the value of 'product bundle'. For didactic reasons, I am going to assume that there is only one condition available that checks the product bundle. In this case, a function has to be written, but it is somewhat counter intuitive. Here is the condition in simple English: check for equality between the order's product bundle and the value which gets returned from the following condition 'if the product bundle is GLASS or CAD then return ! else return the order's product bundle'. So, if the product bundle is GLASS, the condition checks the value ! against the order's product bundle, which fails, as would a product bundle CAD. 'Jim', on the other hand, passes.

In Priority-speak, the rule is

(:$.MODELNAME IN ('GLASS', 'CAD') ? '!' : :$.MODELNAME)

which is more concise than the explanation in English.