Here’s the good news! In my second article about powerful dictionary configurations, I will showcase a time-saving technique to reuse choice list values across your instance. This saves you time and ensures consistency in your data management. This approach is particularly beneficial for multilingual environements, as you only need to translate the main choice list.

Use case 1: Linking Catalog Variables to existing Choice Options

There is a Choice field on a table, and we need to replicate this field on a Catalog Item or Record Producer form with the same choices.

For example, adding the Incident Category drop-down to the “Create Incident” Record Producer. On the left of the screenshot below is the Incident Category field as displayed in the Service Operations Workspace, and on the right is the Create Incident Record Producer in the Employee Service Center Service Portal.

• To get these values onto the “Create Incident” Record Producer Form, create a new Select Box Variable to hold the values that need to be displayed.

• Next, instead of creating mirror Choice options in the Question Choices Related List, navigate to the “Type Specifications” section on the Variable form. Enter the following values and save the variable:
  • Choice table: Incident [incident]
  • Choice field: Category

• Now when we navigate back to the form in the Service Portal, we can see that there is a new Category field on the form, and it already has Choice values that exactly match the Incident Category selections. Now if you change the available Choices for the Incident Category field, the Variable drop-down values will automatically reflect those changes without have to repeat the configuration on the Variable record.

Use case 2: Reuse Choice List values in another field

Sometimes you need to replicate a choices options across several tables and fields to create consistency as data moves from one record to another, like Asset and CI attributes that exist on both records. –OR– You have several fields on the form with the same set of Choice options. For example, a design decision to use Yes/No Choice fields instead of Checkbox fields.

• First, choose which table and field will drive the other fields options. The example will use Incident Category.
• Navigate to the Dictionary record for the other field(s) that will be driven by the Incident Categories.
• Find the Choice List Specification tab. If you don’t see the Choice table field, you may have to switch to Advanced view.
• Enter the following values and save the Dictionary record:
  • Choice table: Incident [incident]
  • Choice field: Category

That’s it! Now, when you change the main field’s list, all of the other choice lists will reflect the change.

Summary

This article explored two simple ways to reuse choice list values in the ServiceNow platform. If you are a customer that supports multiple language, you’ve exponentially saved yourself some time, because you only have to translate the main field’s Choices and those changes will also be reflected everywhere as well.

By leveraging these techniques, you can streamline your ServiceNow configuration and save valuable time!

The post Be a Choice List “Thief” appeared first on ServiceNow Guru.

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.

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.

The post Condition Builder Attributes That Pack a Punch appeared first on ServiceNow Guru.