Mastering Display Fields: A Human Guide to Correct Field Usage in ServiceNow

Ever wondered how those fields on your ServiceNow forms seem to magically know what to show, or why some fields just won’t let you leave them blank? It’s not magic, it’s meticulous configuration! In the vast and powerful world of ServiceNow, fields are the building blocks of every record and every interaction. But simply adding a field isn’t enough; knowing how to make it behave correctly – how it displays, what data it allows, and how it interacts with other fields – is crucial for building intuitive, efficient, and robust applications.

This article will demystify the art and science of field configuration in ServiceNow. We’ll dive deep into what it means to “display” a field, explore the nuances of making fields mandatory or read-only, and unravel the complexities of reference qualifiers and dependent values. Whether you’re a budding ServiceNow administrator, a seasoned developer, or preparing for your next interview, understanding these concepts is fundamental to truly mastering the platform. So, grab a coffee, and let’s get started on making your ServiceNow forms work smarter, not harder!

The ‘Display Field’ Conundrum: Can We Have Two?

Let’s kick things off with a fundamental concept that often trips up even experienced users: the “Display Field” attribute. This isn’t about whether a field is visible on a form (that’s another story we’ll get to later). Instead, the display=true attribute in a field’s dictionary entry tells ServiceNow which specific field’s value should be shown when a record from that table is referenced elsewhere.

Imagine you have a “User” table. When you create an Incident and assign it to a user, how does ServiceNow know whether to show “John Doe,” “john.doe@example.com,” or “JD12345” in the “Assigned to” reference field? It looks for the field marked as display=true in the User table’s dictionary. Usually, this is the “Name” field.

Now, to the burning question: Can we make two fields as display in one table? The short and emphatic answer is: No, you should not!

Why not? Confusion, pure and simple. If you mark two fields as display=true, ServiceNow will get confused about which value to show when referencing a record from that table. While the system might try to pick one (often the first one it encounters or one based on internal logic), this behavior is undocumented, unsupported, and highly unpredictable. It can lead to inconsistent user experiences, data interpretation issues, and frustrating debugging sessions. Best practice dictates that each table should have only one field marked with display=true.

Interview Relevance: This is a classic trick question. Answering “No, because it leads to confusion and unpredictable behavior” demonstrates a deep understanding of ServiceNow’s underlying architecture and best practices.

Making Fields Behave: Mandatory, Read-Only, and More

Controlling field behavior—making fields mandatory, read-only, or hidden—is fundamental to data quality and user experience. ServiceNow offers several powerful mechanisms to achieve this, each suited for different scenarios. Understanding these methods and their scope is key to effective form design.

From Dictionary Properties: The Foundation

The most basic way to define initial field behavior is directly through its dictionary entry.

• Mandatory: Checking the “Mandatory” checkbox here ensures that the field must contain a value before a record can be saved. This is a fundamental, platform-level rule.
• Read-only: Similarly, the “Read only” checkbox makes the field non-editable by users.

When to use: These are for global, always-on rules. If a field should *always* be mandatory or read-only regardless of conditions or context (unless explicitly overridden), this is the place to set it.

Dictionary Overrides: The Special Case for Child Tables

Imagine you have a “Task” table (parent) with a “Priority” field, and its default value is 4 (Medium). Now, you extend “Task” to create an “Incident” table (child). For incidents, you might want the default priority to be 3 (High), or perhaps make the “Short Description” field mandatory specifically for incidents, even if it’s optional on the generic task.

This is where Dictionary Overrides shine. They allow a field in a child table to have a different value or behavior than the same field in its parent table.

What properties can you override? You can override various properties including:

• Default value
• Mandatory
• Read-only
• Active (visibility in the dictionary)
• Reference qualifier
• Choice list specifications
• And many more attributes.

Example: Overriding the “Priority” field on the Incident table to have a default value of “3 – High,” even though the “Task” table (its parent) might default it to “4 – Medium.”

Interview Relevance: A common scenario to explain is customizing inherited fields without affecting the parent table or other child tables. This demonstrates an understanding of table inheritance and efficient customization.

UI Policies: Client-Side Form Control

UI Policies are your go-to for controlling field behavior directly on the form, based on specific conditions. They work on the client side (in the user’s browser), making changes instantly without reloading the page.

You use UI policies to make a field:

• Mandatory: Require user input.
• Read-only: Prevent user modification.
• Visible/Hidden (Display): Show or hide the field altogether.
• They can also show/hide related lists.

Let’s look at some key UI Policy options:

• Global Checkbox: When checked, your UI policy applies across all views of the form. Unchecking it allows you to specify a particular view (e.g., “Default view,” “Self-service view”) where the policy should apply. This is crucial for tailoring experiences for different user groups.
• Reverse if False: This is a powerful little checkbox. If selected, when your UI policy’s condition evaluates to false, the actions defined by the policy are automatically reversed. For instance, if a field was made mandatory when the condition was true, it becomes optional again when false. This prevents you from writing a second UI policy to reverse the first one!
• On Load Checkbox: If checked, the UI policy’s conditions and actions are evaluated and applied immediately when the form loads. If unchecked, the policy only triggers when a field involved in its condition changes. Generally, you’ll want this checked for initial form state setup.
• Inherit Checkbox: When this box is checked, the UI policy you create on a parent table will also apply to all its child tables. This saves you from recreating the same policy across multiple tables in an inheritance hierarchy.
• Can you write script in UI Policy? Yes, absolutely! By enabling the “Run scripts” checkbox, you can execute client-side JavaScript when your UI policy condition is met. This opens up possibilities for more complex client-side logic that goes beyond simple mandatory/read-only/visible actions.

Data Policies: Server-Side Data Integrity

While UI policies control the form experience, Data Policies are about ensuring data integrity regardless of how data enters the system. They work at both the client and server sides, applying rules to all data sources (forms, imports, web services, etc.).

Data policies make fields mandatory or read-only based on conditions, ensuring consistent data quality.

Example: You might use a Data Policy to ensure that the “Assignment Group” field is always mandatory for Incidents with “Critical” priority, even if someone tries to import an incident record via a spreadsheet.

Converting UI Policy to Data Policy: ServiceNow offers a convenient feature: you can convert an existing UI policy into a data policy. Simply open the UI policy and click “Convert to Data Policy.” This is handy for migrating client-side mandatory/read-only rules to the server side.

When UI Policy cannot be converted as Data Policy? There are limitations. A UI policy cannot be converted if it:

• Controls data visibility (i.e., hides fields).
• Controls specific views.
• Controls related lists.
• Contains client-side scripts (Run scripts enabled).

This makes sense because Data Policies operate at the data layer, not the presentation layer. They don’t care about what the user sees on a form or in which view, nor do they execute client-side scripts.

g_form.setMandatory(Script): The Scripting Powerhouse

For highly dynamic or complex scenarios, client scripts (specifically using the g_form API) provide the ultimate flexibility. You can make fields mandatory, read-only, or visible using JavaScript directly.

g_form.setMandatory('field_name', true);
g_form.setReadOnly('field_name', true);
g_form.setVisible('field_name', false);

When to use: When UI policies aren’t flexible enough for your complex logic, or when you need to combine field behavior changes with other client-side actions (e.g., calculations, alerts, API calls).

Interview Relevance: Being able to list these five methods (Dictionary, Overrides, UI Policy, Data Policy, Client Script) and explain their use cases demonstrates a comprehensive understanding of ServiceNow field configuration. Emphasize the client-side vs. server-side distinction.

Setting and Manipulating Field Values

Beyond just controlling how fields behave, we often need to populate them with data. ServiceNow provides straightforward ways to set default values and programmatically assign values using scripts.

Default Values: A Smooth Start to Every Form

You want your users to have a head start, right? Setting a default value on a field means that whenever a new record form is opened, that field will automatically be pre-populated with a specified value. This saves clicks, reduces errors, and streamlines data entry.

Example: Setting the “State” field of a new Incident to “New” or the “Category” to “Hardware” for a specific type of request.

How to set: The most common way is directly in the field’s dictionary entry, in the “Default value” field. This can be a static value, a JavaScript expression, or a predefined system value.

Programmatic Value Assignment: setValue vs. setDisplayValue

When you need to dynamically set field values based on user actions or other logic, scripts are your friend. In server-side scripts (e.g., Business Rules, Script Includes), you’ll often use the current object.

• current.setValue('field_name', value);

  This method sets the actual backend value of a field. For most field types (string, integer, choice), you simply pass the desired value.

  Crucially, for reference type fields, you must provide the sys_id of the referenced record in place of the human-readable value. This is because ServiceNow stores the unique identifier (sys_id) for reference fields, not the display name.

  current.setValue('assigned_to', '9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d'); // Sets assigned_to to a user's sys_id

• current.setDisplayValue('field_name', value);

  This method is a convenience for reference fields. It allows you to set the value using the display value (the human-readable name) of the referenced record, and ServiceNow will automatically look up the corresponding sys_id.

  For reference fields, you give the human-readable value (e.g., “John Doe”), not the sys_id. If the display value is unique, this works seamlessly. If there are multiple records with the same display value, it might pick the first one it finds, which can be risky.

  current.setDisplayValue('assigned_to', 'John Doe'); // ServiceNow finds John Doe's sys_id

When to use which? setValue is generally safer and more precise for reference fields if you already have the sys_id. setDisplayValue is convenient when you only have the display name but be mindful of potential ambiguity if display names aren’t unique. For non-reference fields, setValue is the standard.

Mastering Reference Fields: Qualifiers, Dependencies, and More

Reference fields are incredibly powerful, allowing you to link records across tables. But without proper control, they can present users with overwhelming lists of options. This is where qualifiers, dependencies, and calculated values come into play, making your forms smarter and more user-friendly.

Reference Qualifiers: Filtering the Noise

Reference Qualifiers are like bouncers for your reference fields. They restrict the data shown in reference and List type fields, ensuring users only see relevant options. This is critical for data accuracy and a streamlined user experience. There are three main types:

Simple Reference Qualifier

• Description: This is the most basic form. You define a fixed query to filter the referenced records. It’s static and doesn’t change based on form context.
• Example: You want the “Assigned To” field to only show active users.
• How to Use: In the reference field’s dictionary entry, find the “Reference qualifier” field and enter a simple query string.

  active=true

  This would show only active users from the User table.

Dynamic Reference Qualifier

• Description: This type uses a pre-defined “Dynamic Filter Option” to generate a query that can adapt based on the context of the current record or user. It’s more flexible than simple qualifiers but relies on pre-configured options.
• Example: Displaying only incidents assigned to the same assignment group as the current user. Or showing only CIs that are “In Use.”
• How to Use:
  1. First, create a Dynamic Filter Option via System Definition > Dynamic Filter Options. Define your conditions there.
  2. Then, in the reference field’s dictionary entry, select “Dynamic” for the “Reference qualifier” type and choose your created Dynamic Filter Option.
• Difference from Simple: Simple is a static string; Dynamic uses a reusable, pre-defined filter that can incorporate some context (like `[Me]`, `[My Groups]`) without needing JavaScript.

Advanced Reference Qualifier (JavaScript Reference Qualifier)

• Description: This is the most powerful and flexible type. It uses a custom JavaScript code to define complex queries for the reference field. It allows for dynamic filtering based on multiple conditions, values of other fields on the current form, and complex logic.
• Example: Filtering the “Affected CI” field to show only CIs associated with the current user’s location AND are of a specific class (e.g., “Laptop”).
• How to Use: In the reference field’s dictionary entry, select “Advanced” for the “Reference qualifier” type and enter JavaScript code. The script must return a valid encoded query string.

  javascript: 'assignment_group=' + current.assignment_group + '^priority<3';
  This would filter incidents to only those assigned to the same group as the current incident AND having a priority less than 3.

• Difference from Dynamic: While Dynamic uses pre-configured options with some context, Advanced allows for fully custom, script-driven logic to build the query string dynamically, often using values from the `current` object or other variables.
• Difference from Simple: Simple is a static query string. Advanced is JavaScript code that *generates* a query string, allowing for dynamic and conditional filtering.

Interview Relevance: Explaining all three types, their use cases, and especially the differences between them (simple vs. dynamic, dynamic vs. advanced, simple vs. advanced) demonstrates a deep understanding of reference field filtering, which is crucial for building robust applications.

Dependent Values: Building Intelligent Forms

Dependent values are all about creating cascading dropdowns or picklists, where the choices in one field change based on the selection made in another. Think of it like a smart menu: choose "Appetizers," and you get a list of starters; choose "Main Course," and you see entrees.

This is incredibly useful for guiding users, preventing incorrect selections, and simplifying complex forms.

Steps to Configure Dependent Values:

1. Identify Parent and Dependent Fields: First, decide which field will be the "parent" (e.g., "Category") and which will be the "dependent" (e.g., "Subcategory").
2. Configure the Parent Field: Ensure your parent field has its list of possible values defined (e.g., choices for "Hardware," "Software," "Network").
3. Configure the Dependent Field:
   • Go to the dictionary entry of the dependent field.
   • Set the Dependent Field attribute to the parent field.
   • Now, for each choice in the dependent field, you'll specify its "Dependent value" – which parent choice it belongs to.

Parent Field: Category (Choices: Hardware, Software, Network)
Dependent Field: Subcategory (Dependent on Category)

Define choices for Subcategory:

• If Category = Hardware: Laptop, Desktop, Printer
• If Category = Software: Operating System, Application, Database
• If Category = Network: Router, Switch, Firewall

With this setup, when a user selects "Hardware" in the Category field, the Subcategory dropdown will dynamically update to show only "Laptop," "Desktop," and "Printer." Neat, right?

Interview Relevance: Dependent values are a core feature for building user-friendly forms. Explaining the concept and configuration steps shows practical application knowledge.

Calculated Values: When Fields Do the Math

Sometimes, a field's value isn't directly input by a user but rather derived from other fields on the same record. This is where Calculated Values come in.

If you want to calculate a field value based on other field values using the current object (server-side), you can use the "Calculated" dictionary property. When checked, a "Calculation" field appears where you can write a server-side JavaScript script. This script will execute whenever the record is saved, calculating and populating the field's value.

Example: Calculating an "Estimated Resolution Time" based on "Priority" and "Impact" fields. Or, calculating a "Total Cost" field based on "Quantity" and "Unit Price."

Important: Calculated fields are server-side and perform their calculations upon record submission or retrieval. If you need immediate, client-side calculation as the user types, you'd typically use a client script.

Beyond the Basics: Attributes, Collections, and Overrides

ServiceNow provides even more granular control over fields through attributes and special dictionary entries.

Field Attributes: Fine-Tuning Behavior

Attributes are extra properties you can add to a field's dictionary entry to change its behavior or appearance in specific ways that aren't covered by standard checkboxes. They are essentially key-value pairs that influence how the platform handles and renders the field.

Some common attributes you might use include:

• no_email=true: Prevents this field's value from being included in email notifications.
• no_attachment=true: Prevents attachments from being added to the form (this is typically set on the Collection field, as discussed next, but conceptually it relates to this).
• tree_picker=true: Displays a hierarchical tree picker for reference fields instead of a standard lookup.
• alt_readonly=true: Makes a field read-only only for non-admin users.
• widget=sn_picture_widget: Can be used for image fields to display the image.

You add attributes in the "Attributes" field on the dictionary entry, separated by commas.

The Collection Field: Table-Level Control

Every table in ServiceNow has a special dictionary entry of type "Collection." This entry doesn't represent a specific field but rather the table itself. Changes applied to this Collection field dictionary entry affect the entire table.

How to enable/disable attachment on the form using attributes? You would go to the dictionary entry for your table where the "Type" is "Collection" (e.g., for the Incident table, find the dictionary entry for `incident` where type is `Collection`). In the "Attributes" field, you would add:
no_attachment=true

This attribute, applied at the collection level, will disable attachments for all forms associated with that table.

Interview Relevance: Understanding the Collection field demonstrates an awareness of table-level configurations, not just field-level.

Process Flow: Indicating State and Progress

While not directly a "field" in the traditional sense, the Process Flow is a crucial display element on many ServiceNow forms, especially for records that go through a lifecycle (e.g., Incidents, Requests, Changes).

A process flow is a visual indication that shows the current state or stage of the record on which you are. It typically appears as a series of steps or "bubbles" at the top of a form, highlighting the current active stage. It helps users quickly understand where a record is in its workflow.

Configuration: Process flows are usually driven by the "State" or "Workflow Stage" field values, mapped to specific stages in a workflow or flow designer.

Troubleshooting Common Field Issues

Even with all this knowledge, you might encounter situations where fields don't behave as expected. Here are some common troubleshooting tips:

• Conflicting Rules: If a field isn't mandatory when it should be, or vice-versa, check for conflicting rules. A UI Policy might be setting it optional, while a Data Policy is trying to make it mandatory. Generally, Data Policies (server-side) have precedence over UI Policies (client-side) for mandatory/read-only. Client scripts have the highest precedence on the client side.
• Order of Execution: For client scripts and UI Policies, the order matters. If multiple scripts/policies affect the same field, ensure they execute in the desired sequence.
• Caching: Sometimes, browser or instance cache can cause unexpected behavior. Clear your browser cache or perform a cache flush on the instance (`cache.do`) if changes aren't reflecting.
• View-Specific Issues: Remember the "Global" checkbox in UI Policies? If a field behaves differently for some users, check if a UI Policy is view-specific or if a different view is being applied.
• Reference Qualifier Debugging: For advanced reference qualifiers, use the "ref_qual_elements" debugger. Open the form, right-click the reference field label, and select "Show XML." Look for the "ref_qual_elements" attribute to see the generated query. This helps identify issues in your JavaScript.
• Mandatory Field Not Visible: If a mandatory field is hidden by a UI Policy or Client Script, the user won't be able to save the record, leading to frustration. Always ensure mandatory fields are visible when their conditions are met.

Interview Relevance & Key Takeaways

The concepts discussed here are not just theoretical; they are practical tools every ServiceNow professional uses daily. In an interview, demonstrating a solid grasp of these topics can set you apart:

• The "Two Display Fields" question (Q43): A great way to show your understanding of fundamental ServiceNow architecture.
• Mandatory/Read-only methods (Q42): Being able to list and explain Dictionary, Overrides, UI Policies, Data Policies, and Client Scripts showcases comprehensive knowledge.
• setValue vs. setDisplayValue (Q47): Highlights your scripting proficiency and attention to detail, especially with reference fields.
• Reference Qualifiers (Q48): A detailed explanation of Simple, Dynamic, and Advanced types, along with their differences, proves your ability to build smart, efficient forms.
• UI Policy vs. Data Policy (Q58, Q66): Understanding the client-side vs. server-side distinction and when to use each is critical.
• Dictionary Overrides (Q54): Demonstrates your ability to manage inheritance and customize child tables effectively.

In essence, mastering field configuration in ServiceNow is about balancing user experience with data integrity. It’s about building forms that are intuitive, preventing bad data from entering the system, and ensuring that the right information is presented to the right people at the right time.

Conclusion

From the subtle intricacies of the display=true attribute to the robust power of Data Policies and advanced reference qualifiers, correctly using display fields in ServiceNow is a skill that blends technical know-how with an understanding of user experience. We've explored the myriad ways to control field behavior, populate values, filter selections, and ensure data quality, all while keeping the human element and practical application in mind.

Remember, the goal isn't just to make fields work, but to make them work smartly, contributing to a seamless, efficient, and error-free experience for your users. Keep experimenting, keep learning, and keep building amazing things in ServiceNow!