Field Types and Attributes

Field Types and Attributes in ServiceNow – A Comprehensive Guide for CAD Exam Preparation

Introduction

Understanding field types and attributes is a foundational skill for anyone designing and creating applications on the ServiceNow platform. Whether you are building a custom application from scratch or extending an existing one, the fields you define on your tables determine how data is captured, stored, validated, and displayed. For the ServiceNow Certified Application Developer (CAD) exam, this topic is critical because it tests your ability to choose the right field type for a given requirement and configure attributes that enforce business rules at the data layer.

Why Field Types and Attributes Are Important

Field types and attributes serve as the backbone of data integrity and user experience in ServiceNow. Here is why they matter:

1. Data Integrity: Selecting the correct field type ensures that only valid data can be entered. For example, using an Integer field prevents users from entering alphabetic characters where only numbers are expected.

2. User Experience: The field type determines the input widget rendered on a form. A Date field presents a date picker, a Reference field presents a lookup, and a Choice field presents a dropdown. Choosing the right type makes forms intuitive.

3. Performance: Properly typed fields allow the database to index and query data efficiently. Misusing field types (e.g., storing dates as strings) can degrade reporting and list performance.

4. Business Logic: Many server-side and client-side scripts depend on field types. Conditions, workflows, flow designer actions, and ACLs all behave differently based on the underlying field type.

5. Platform Consistency: ServiceNow's out-of-the-box modules rely on standard field types. Using them correctly ensures compatibility with platform features like dot-walking, reporting, and service portal widgets.

What Are Field Types?

A field type defines the kind of data a column in a ServiceNow table can hold. When you add a column to a table (via the table editor, form designer, or directly through the Dictionary), you must specify its type. ServiceNow offers a wide range of field types. Below are the most important ones for the CAD exam:

Common Field Types:

• String: Stores short text values. Default max length is 40 characters but can be extended up to 4000. Rendered as a single-line text input.

• Integer: Stores whole numbers. Useful for counters, quantities, and numeric identifiers.

• Long: Stores large whole numbers beyond the range of Integer.

• Floating Point Number: Stores decimal numbers. Note that this type can have precision issues; for financial calculations, Decimal is preferred.

• Decimal: Stores precise decimal numbers. Ideal for currency or measurements requiring exact precision.

• True/False (Boolean): Stores a binary value (true or false). Rendered as a checkbox on forms.

• Date: Stores a date value without a time component. Rendered with a date picker widget.

• Date/Time: Stores both date and time. The platform handles timezone conversion automatically based on user preferences.

• Choice: Stores a value from a predefined list of options. Rendered as a dropdown. Choices can be defined in the Choice table or via a dependent choice list.

• Reference: Creates a foreign key relationship to another table. Rendered as a reference lookup field with auto-complete. This is one of the most commonly tested types on the exam.

• Glide List: Stores multiple reference values (a comma-separated list of sys_ids). Allows users to select multiple records from a referenced table.

• Journal: Stores entries that are appended over time and cannot be edited once saved. Used for activity logs and additional comments.

• Journal Input: A write-only field that allows adding journal entries. The entries themselves are stored in the Journal field. Work Notes and Additional Comments are journal input fields.

• HTML: Stores HTML-formatted content. Rendered with an HTML editor widget on forms.

• URL: Stores a web address. Rendered as a clickable hyperlink.

• Email: Stores an email address with basic format validation.

• Phone Number: Stores phone numbers with appropriate formatting.

• Currency: Stores a monetary amount along with a currency code. Supports multi-currency environments.

• Price: Similar to Currency but used specifically in the Service Catalog context.

• Duration: Stores a time span (e.g., 2 hours, 30 minutes). Rendered with a duration picker.

• Document ID: A special reference type that can point to a record on any table. It stores both the table name and sys_id.

• Conditions: Stores a query condition (encoded query). Used in features like filters, ACLs, and UI policies. Rendered as a condition builder widget.

• Script: Stores JavaScript code. Rendered with a code editor that includes syntax highlighting.

• Template Value: Stores name-value pairs used in record templates.

• Translated Text: Similar to String but supports translation into multiple languages.

• Image: Stores an image reference (typically a sys_id pointing to an attachment).

• IP Address: Stores IPv4 or IPv6 addresses with appropriate validation.

What Are Field Attributes?

Field attributes are metadata properties that modify or enhance the behavior of a field beyond what the field type alone provides. Attributes are set in the Attributes field of the Dictionary Entry (sys_dictionary) record for a given column. They are entered as comma-separated key=value pairs (or just keys for boolean-style attributes).

Key Field Attributes:

• edge_encryption_enabled=true: Enables edge encryption for the field's data at rest.

• max_length=n: Overrides the default maximum character length for string-type fields.

• no_sort=true: Prevents users from sorting a list by this column.

• no_filter=true: Prevents the field from appearing in filter conditions.

• is_searchable=true: Includes the field in text search indexes.

• ref_auto_completer=AJAXReferenceCompleter: Specifies the auto-completer class used by a Reference field.

• ref_ac_columns=field1;field2: Defines which additional columns are shown in the reference auto-complete dropdown.

• ref_ac_columns_search=true: Enables searching across the columns specified in ref_ac_columns.

• ref_ac_display_value=true: Shows the display value rather than the sys_id in reference auto-complete results.

• ref_ac_order_by=field_name: Specifies the sort order for auto-complete results.

• ref_contributions=...: Used to add reference qualifier contributions.

• ref_qual_elements=field1,field2: Specifies which fields on the current form should trigger a refresh of the reference qualifier when they change.

• tree_picker=true: Renders a reference field as a hierarchical tree picker instead of a standard lookup.

• dependent_on_field=field_name: Used with Choice fields to create dependent choice lists.

• default_rows=n: Sets the default number of visible rows for multi-line text fields.

• glide_list=true: Enables Glide List behavior (comma-separated sys_ids) for a field.

• slushbucket=true: Renders a Glide List field as a dual-list (slushbucket) picker instead of a comma-separated text input.

• email_client=true: When set on a list collector or email field, it integrates with the email client.

• no_audit=true: Excludes the field from being tracked in the audit history.

How Field Types and Attributes Work Together

When you create or modify a field in ServiceNow, the platform writes a record to the sys_dictionary table. This record contains:

• The table name
• The column name (element)
• The field type (internal_type referencing sys_glide_object)
• The max length
• The default value
• The reference table (if applicable)
• The attributes (a string of comma-separated attribute directives)
• Whether the field is mandatory, read-only, active, etc.

The rendering engine reads the dictionary entry to determine how to display the field on a form or list. The field type dictates the base widget, and the attributes modify that widget's behavior. For example, a Reference field type automatically renders a lookup icon and auto-complete input. Adding the attribute ref_ac_columns=name;email modifies the auto-complete to also search and display the name and email columns from the referenced table.

How to Configure Field Types and Attributes

There are several ways to configure field types and attributes in ServiceNow:

1. Table Editor: Navigate to a table definition and use the Columns tab to add or modify fields. The type dropdown lets you select the field type, and you can set attributes in the advanced view.

2. Form Designer: Drag and drop fields onto a form layout. You can create new fields directly from the form designer, selecting the type from a list.

3. Dictionary Record (sys_dictionary): For fine-grained control, navigate directly to the dictionary record for a field. This is where you set attributes, reference qualifiers, and other advanced configurations.

4. Studio / App Engine Studio: When building scoped applications, you can define fields through the integrated development environment which provides a guided experience for selecting types and setting attributes.

5. Right-click on Form Label: Right-clicking a field label on a form and selecting Configure Dictionary takes you directly to the dictionary entry for that field.

Important Concepts for the CAD Exam

1. Reference Fields and Dot-Walking: Reference fields create relationships between tables. You can dot-walk through reference fields to access fields on the referenced table (e.g., caller_id.email on the Incident table accesses the email of the caller). Understanding this is critical for scripting, conditions, and reporting.

2. Reference Qualifiers: A reference qualifier limits the records available in a Reference field's lookup. It can be a simple filter (e.g., active=true), a dynamic filter using javascript: prefix, or a scripted reference qualifier using a Script Include. The exam frequently tests this concept.

3. Choice Fields vs. Reference Fields: Know when to use a Choice field (small, static list of options stored in sys_choice) versus a Reference field (dynamic list pointing to another table). If the list of options may grow or if you need additional data about each option, use a Reference field.

4. Dependent Choice Lists: Choice fields can be configured so that the available choices depend on the value of another field. This is configured using the Dependent field attribute on the dictionary entry or through the dependent choice list configuration.

5. Journal Fields: Understand the difference between Journal and Journal Input types. Journal entries are append-only and timestamped. Work Notes and Additional Comments on the Task table are prime examples. Journal fields do not appear in standard reporting queries and require special handling.

6. String vs. Translated Text: Use Translated Text when internationalization is required. The platform stores translations in the sys_translated_text table.

7. Field Type Inheritance: When a table extends another table, it inherits all the parent table's fields. You can add new fields to the child table but cannot change the type of inherited fields at the child level without creating a dictionary override.

8. Dictionary Overrides: Dictionary overrides (sys_dictionary_override) allow you to change certain properties of an inherited field at the child table level, such as the default value, mandatory setting, read-only setting, and reference qualifier. You cannot change the field type through a dictionary override.

9. Max Length Considerations: The default max length varies by type (String = 40, Choice = 40, etc.). When you need longer text, you can increase the max length or switch to a Large String (up to 4000) or a String (Full UTF-8) type. For very large text, consider using the Journal or HTML type.

10. Calculated Fields: A field can be marked as calculated, meaning its value is derived from a script rather than direct user input. This is configured in the dictionary entry and uses a calculated value script.


Exam Tips: Answering Questions on Field Types and Attributes

The CAD exam tests both conceptual knowledge and practical application of field types and attributes. Here are targeted tips to help you succeed:

Tip 1: Know the Most Common Field Types by Heart
Memorize the behavior of String, Integer, Boolean, Date/Time, Choice, Reference, Glide List, Journal, and Conditions field types. Most exam questions revolve around these. Be able to identify the correct type based on a scenario description.

Tip 2: Understand Reference Field Mechanics Deeply
Reference fields are heavily tested. Know that they store a sys_id, support dot-walking, can have reference qualifiers (simple, dynamic, advanced/scripted), and display the display value of the referenced record. Know how ref_ac_columns and ref_qual_elements attributes work.

Tip 3: Distinguish Between Similar Types
The exam may present options that are close but different. Key distinctions to remember:
- Choice vs. Reference: Choice stores the value directly; Reference stores a sys_id pointing to another table.
- String vs. Translated Text: Translated Text supports i18n; String does not.
- Journal vs. Journal Input: Journal is the stored field; Journal Input is the write-only entry point.
- Currency vs. Price: Both store monetary values, but Price is specifically for catalog items.
- Integer vs. Long vs. Floating Point vs. Decimal: Know precision and range differences.
- Document ID vs. Reference: Document ID can reference any table; Reference is fixed to one table.

Tip 4: Recognize Attribute Syntax
Attributes are comma-separated key=value pairs in the dictionary entry. If an exam question shows something like ref_ac_columns=name;email,ref_ac_columns_search=true, you should recognize that this configures the auto-complete behavior of a Reference field to search across name and email columns.

Tip 5: Understand When Dictionary Overrides Apply
If a question describes a scenario where you need to change the default value or mandatory status of a field on a child table, the answer is typically a dictionary override. Remember that you cannot change the field type via a dictionary override.

Tip 6: Read the Scenario Carefully
Many questions describe a business requirement and ask you to choose the best field type. Look for keywords:
- "Select one option from a list" → Choice or Reference
- "Select multiple records" → Glide List (List type) or related list
- "Track all updates chronologically" → Journal
- "Store a link to another record" → Reference
- "True or false toggle" → True/False (Boolean)
- "User enters a date" → Date or Date/Time
- "Condition or filter" → Conditions field type
- "Store a script" → Script field type

Tip 7: Know How to Set Up Dependent Choice Lists
The exam may ask about configuring dependent dropdowns. Remember that you need a parent Choice field and a child Choice field. The child field's dictionary entry must specify the parent in the Dependent field property. Choices for the child field are then associated with specific values of the parent field.

Tip 8: Understand the Conditions Field Type
This field type stores encoded queries and renders as a condition builder. It is used extensively in notifications, scheduled jobs, ACLs, and other configurations where dynamic filtering is needed.

Tip 9: Pay Attention to Scoped Application Restrictions
In scoped applications, certain field types and operations may be restricted. For example, you might not be able to create fields on tables outside your application scope without cross-scope access policies. The exam may test this awareness.

Tip 10: Practice in a Personal Developer Instance (PDI)
The best way to internalize field types and attributes is hands-on practice. Create a custom table in your PDI, add fields of various types, experiment with attributes, and observe how the form and list views change. Try configuring reference qualifiers, dependent choice lists, and calculated fields.

Tip 11: Eliminate Obviously Wrong Answers
On multiple-choice questions, start by eliminating answers that are clearly incorrect. For example, if a question asks about displaying a hierarchical category selector, and one option says "String field with tree_picker attribute" while another says "Reference field with tree_picker attribute," eliminate the String option because tree_picker is a Reference field attribute.

Tip 12: Remember That Attributes Modify Default Behavior
If a question describes custom behavior on a standard field type (like showing extra columns in a reference lookup or preventing a field from being filtered), the answer likely involves an attribute. Think about which attribute achieves the described modification.

Summary

Field types and attributes are essential building blocks for ServiceNow application development. Field types define the nature of the data stored (text, number, date, reference, etc.) and determine the input widget rendered on forms. Attributes fine-tune field behavior, controlling everything from auto-complete columns on reference fields to encryption and audit settings. For the CAD exam, focus on understanding the most commonly used field types, their differences, reference field mechanics (including reference qualifiers and dot-walking), dictionary overrides, and the syntax and purpose of key attributes. Combine this knowledge with hands-on practice in a PDI, and you will be well-prepared to answer any question on this topic confidently.