Condition Builder Attributes That Pack a Punch

Condition builders are the backbone of powerful filtering and automation within ServiceNow. They allow you to define precise criteria for workflows, reports, and many other areas of the platform.

Did you know there are dictionary attributes you can apply to the standard condition builder field that will supercharge your filtering capabilities?

Let’s dive into my top four condition builder field attributes that deliver significant impact with little effort!

1. condition_builder=v2 – The Modernized Interface

Condition builder fields have a more accessible, intuitive interface. Enabling this modern user experience simply requires setting condition_builder=v2 in the dictionary attributes for a Conditions field.

My favorite part is that the new interface eliminates the endless drop-down reloading when you dot-walk through several reference fields.

Without Condition Builder v2 With Condition Builder v2

2. show_condition_count – (Near) Real-Time Feedback

Ever wonder how many records your current filter criteria will return? show_condition_count is your answer. When set to true, the condition builder will display the number of matching records when you hit Preview.

This provides invaluable feedback, helping you refine your filters and avoid unexpected results. It’s especially useful when dealing with large datasets.

3. readable – Human-Friendly Conditions

Complex conditions can quickly become cryptic and challenging to understand. The readable attribute addresses this issue. When set to true, ServiceNow displays a human-readable version of your condition in Lists and settings where the condition field is read-only.

For instance, instead of seeing:

active=true^assignment_group=d625dccec0a8016700a222a0f7900d06

You’ll get:

Active is true AND Assignment group is Service Desk


Another attribute that can be used in conjunction with readable is no_truncate=true. This prevents the value from getting truncated in a list view, as you see above. I recommend considering the expected length of a typical condition for your table. If you think they will be lengthy, I would not recommend using the no_truncate attribute. The trade-off is that each record row will take up a lot of space on your screen. You can always remove the no_truncate attribute or set it to no_truncate=false later if it proves to be unwieldy.

4. allow_related_list_query – Querying Beyond the Current Table

By default, condition builders limit your queries to the fields of the current table you’re working with. But what if you need to filter based on data in a related table? That’s where allow_related_list_query comes in.

Setting this attribute to true opens up a world of possibilities. You can now construct queries that traverse relationships between tables. For example, you could filter incidents based on the priority of the associated change request.

Within the Related list query, there are three components:

  1. Quantity: such as Greater than, Less than, or None
  2. Table relationship: How does the Related Record link to the primary record?
  3. Filter: You must specify a condition. Using the Incident and Change Request example from above, specify “Priority is 3 – Moderate.” Suppose you are just looking for the existence of one record that uses the specified Table relationship. In that case, I recommend finding a condition that will always be true, like “Number is not empty.”

In the image below, you can see an example primary record condition of “Active is true AND Assignment group is Service Desk” and a condition for “At least on Change Request record where the primary record is the Parent, and the Change Request Priority is 3 – Moderate”

NOTE: Unfortunately, the Related Record conditions are not formatted for readable viewing.

Important! Be mindful of performance when using related list queries, as they can potentially impact system resources if not designed carefully.

How to activate these options

You’ll need to modify the Attributes fields on the Dictionary record for each field.

  1. Navigate to a form with a condition builder field.
  2. Right-click on the field label, for the field you want to modify, then click Configure Dictionary.
  3. In the Attributes field, add the desired setting, such as condition_builder=v2 or allow_related_list_query=true. For multiple attributes, separate by comma.
  4. Click Update.

If you have activated all the options above, the attributes field on the dictionary record will look like the string below. The order in which these attributes are listed is not important.

condition_builder=v2,show_condition_count=true,readable=true,no_truncate=true,allow_related_list_query=true

To deactivate or reset to default, you can reverse the procedure above, removing the added text from the Dictionary Attribute field.

Date Posted:

June 11, 2024

Share This:

7 Comments

  1. Dharma Liyanage June 11, 2024 at 5:50 pm - Reply

    Thank you for sharing your knowledge.

    • Trinny June 11, 2024 at 8:59 pm - Reply

      Wonderful tips and tricks you are sharing!

  2. Fred June 12, 2024 at 9:58 am - Reply

    What field would you actually add these attributes to?

    • Carleen Carter June 13, 2024 at 10:02 pm - Reply

      Any number of places! In one of my PDIs, almost 50% of the condition builder fields (internal_type=conditions) do not have condition_builder=v2 in the Attributes. If there is a field where you must set up rules that frequently dot-walk through reference fields, the time saved on the drop-down reloading alone is worth it!

      If you are building a new application, condition fields are a powerful tool to make it more dynamic and data-driven. They also empower non-admin users by allowing them to configure rules. For instance, I recently built a table that enables process admins to automatically set the conditions to apply categories. This way, categories would be applied uniformly, increasing reporting accuracy and giving non-admin users a greater role in the process.

      If you are interested in using a Condition field in a new application, check out the GlideFilter API in the ServiceNow documentation. The methods in this API allow you to take the value of the condition fields and compare it to a GlideRecord to see if there is a match.

  3. David Rosevold June 12, 2024 at 5:17 pm - Reply

    Displaying Condition Builder v2 as the default. Great info!

  4. Shu Liu June 12, 2024 at 9:03 pm - Reply

    Love it, Thank you for sharing

  5. Keith Mildren June 13, 2024 at 1:09 am - Reply

    This is really good. I appreciate you sharing. Will definitely use it in the future .

Leave A Comment

Categories

Tags

Loading

Fresh Content
Direct to Your Inbox

Just add your email and hit subscribe to stay informed.