Process condtions are used as either pre-conditions or decisions in a process and widely used. They perform a comparison on an attribute and return either a Yes or No (True of False) result which is used to direct the process flow or limit which actions are available at a status. This document describes how a calculations condition can overcome an old limitation with process conditions. Service Desk 7.3 or higher is required.
The existing limitation
There has always been one limitation that many have reqeusted be addressed with condtiions. This is that conditions can only ever be based on one comparison. For example if you want an action on an incident to only be avaiable when a certain Boolean is checked this is already possible by creating a pre-condition with the following condition setup:
However you can't add any further complaexity to the comparison. If you want the action to only be available when the Boolean is checked AND if the incident is of a certain category this is not possible. You could create a seperate condition for the comparison on the category but there is no way to combine or stack the two conditions for use in the process.
How calculations can help
The Process Designer documentation will show how you can use a calculation as the basis of one side of a condition comparison. This means you can take a value you couldn't get to before or calculate a numerical result of a formula and compare this as normal to an explicit or runtime value. There is however another way to look at how a calculation can be used in a comparison and it is this technique that allows us to create conditions on multiple comparisons.
Using logic-based calculations
Using the above example of the Boolean flag and selected category we can use logic within the calculation itself to determine the True or False result we want in our condition. The result of the calculation can then be compared to "True" in our condition. The condition itself is then only checking if True or False equals True and the logic behind that True of False calculation result can be as complex as we want.
The condition on this example (and any other example of this technique) simply looks like this:
Note the main difference is the Condition Type is Calculation instead of Standard so the basis of the comparison is the result of the calculation instead of a static attribute.
The calculation formula itself (accessed by clicing the eplisis '...' icon on the Calculation Formula field) looks like this:
static def GetAttributeValue(Incident):
Value = 'False'
if Incident._MajorIncident.ToString() == 'True' and Incident.Category.FullName == 'Hardware': Value = 'True'
The formula initially sets the variable Value to False, then changes this to True if both the conditions of the If statement match. The "and" operator is used to say both must match but you could replace this with an "or" so that the condition is met if either one or the other conditions match. The formula could spread over many lines and check against many different attributes/variables depending on what you want the process condition to check against.
The language used in calculations formulae is well documented, for more information please refer to: Calculation formula writing: Further reading on the Boo scripting language and .NET Framework
Testing the calculation logic
If your calculation is complex you may need to go back and edit the formula multiple times to get it right. Once yo've created a condition and added it to the process you can't edit the condition unless you remove it from the process diagram, so making quick changes to the calculation formula is not so quick.
Instead the best way to test these calculations is to create them as AfterRead calculations on an attribute before you even create the process condition. You can then quickly make changes to the calculation and open a test incident already at the right status and instantly see the result of the formula. You can create the calculation on either a String or Boolean attribute. A Boolean attribute will show as checked if the calculation returns True.
Once you've got the calculation formula right you can copy/paste it from your test attribute knowing the logic is there. You should always delete the test attribute once it is no longer needed otherwise it will cause an unecessary load on the server going forward.
Factors to bear in mind
When using a calculation in this way there are some important factors to bear in mind:
1. The more complex the calculation is the more processing and database power it will take.
2. If there is an error in the calculation it will return NULL. This will cause the condition to return a No/False because NULL is not equal to True.
3. The calculation can read any attribute related to the object in use (Incident in the above example) however it cannot read macro values such as Current User or Current Group.