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 |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [](https://servicenowguru.com/wp-content/uploads/2024/06/without%5Fcondition%5Fbuilder%5Fv2.png) | [](https://servicenowguru.com/wp-content/uploads/2024/06/with%5Fcondition%5Fbuilder%5Fv2.png) |

##

## 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.

[](https://servicenowguru.com/wp-content/uploads/2024/06/show%5Fcondition%5Fcount.png)

## 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` ``

[](https://servicenowguru.com/wp-content/uploads/2024/06/without%5Freadable.png)

You’ll get:

Active is true AND Assignment group is Service Desk

[](https://servicenowguru.com/wp-content/uploads/2024/06/with%5Freadable.png)
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.

[](https://servicenowguru.com/wp-content/uploads/2024/06/allow%5Frelated%5Flist%5Fquery%5Fexample.png)

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`

[](https://servicenowguru.com/wp-content/uploads/2024/06/condition%5Fbuilder%5Fattributes.png)

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