Condition Builder Logic

#Logic , #Condition Builder

Andrew Barnes

3 minute read

Conditions

Conditions live in quite a few places in our lives as developers. In ServiceNow, they play an important role not just in our code, but also spread throughout the Graphical Interfaces in the no/low code components. The condition builder has flexibility and some common pitfalls that we are going to explore in this article.

Empty Condition Builder

The condition builder starts with a field, an operator, and the operator’s inputs. Which operator and the types and numbers of inputs depend on the field type being selected. As an example lets compare the operators available for a string field against a date field.

Operators

Now let’s dive into some of those operators and the flexibility and power they make available to you. You are given a requirement to report on the number of incidents closed outside the regular 8-5 hours during the week. Using trend helps us get information just like this. You can choose from an extensive list of trend time choices to help build the condition.

Weekday off hours conditions

Similar to trend is relative. It is one of the lesser known and yet more powerful operators available. Relative provides for convenient use of time corresponding to the current time. It is particularly useful when the between operator doesn’t have the granularity to bound a time in a manner you need. The real strength of these operators comes when using them together. Below you can see ‘relative’ combined with ‘is more than’ to hone in on a particular set of data.

Relative

logic

With all those operators under our belts, we can take a look at some common errors to avoid. The most common is the following scenario. The filter is all built and working great for, Active, not updated in the past two days, and the assignment group is not ‘architects’. Then the report owners want to exclude the 2nd group as their data isn’t relevant. They will most likely set it up in the following manner.

Or Condition Example

This will start returning results for both the architects and database teams. The issue here is that Not A OR Not D isn’t the same as what the report owner wanted which is NOT (A OR D). Since we can’t throw a negation on a group of condition lines, we have to learn how to convert what we want into what we have available. This process is done by moving our NOT inside the parenthesis and applying it to all the elements including the operator (OR). Each becomes its opposite A -> NOT A, OR -> AND, D -> NOT D. Resulting in (NOT A AND NOT D) which we can see below.

AND Condition Example

How does the condition builder interact with the older style condition field present in many places you might ask. They are both evaluated, and you can treat them as if there was an AND operator between them. The condition field is useful for when you have complicated scripted conditions and need scripting access. For really complicated conditions, utilizing a script include holding the logic and script is useful. A condition utility script include with common reusable methods is a potent tool.

Conclusions

I hope you enjoyed this article on Conditions. If you have any other tips and gotchas, you would like to share, place them in the comments below. I will update the article with your ideas!

Comments