Data Type Selection for ServiceNow Custom Scoped Applications

CMa_yfield · 2 hours ago

Field data type selection is not a cosmetic UI decision—it's a strategic architecture choice that determines application scalability, reporting capability, and business autonomy for years to come. Choose incorrectly, and you inherit technical debt, reporting blind spots, and unnecessary developer intervention for simple data value updates. Choose correctly, and you enable self-service data management, actionable analytics, and maintainable data models.

This article provides a tactical decision framework for ServiceNow custom-scoped application developers and architects, with business-friendly translations to facilitate communication with non-technical stakeholders.

Data Normalization: The Reporting Imperative

Normalized vs. Non-Normalized Data

Understanding data normalization is fundamental to field type selection:

Choice fields: Normalized—discrete, predefined values stored in sys_choice table
Reference fields: Normalized—discrete values stored in dedicated reference tables
String fields: Non-normalized—free-text with no value constraints

Both Choice and Reference field values can be shared across multiple fields within your application, preventing data duplication in your custom scoped application data model. For example, a single Department choice list can be referenced by five different fields across multiple tables, maintaining a single source of truth. This is the way a single integrated data model is supposed to work and this is one of ServiceNow’s SUPER POWERS!

Reporting Impact

The normalization difference has immediate reporting consequences:

Normalized data (Choice/Reference): Can group by, aggregate, create pie charts, and bar charts (scripting is required for using list fields of reference values)
Non-normalized data (String): Cannot effectively report—each entry is potentially unique

Consider department tracking across 500 incident records. With a String field, you'll encounter 500 variations: "IT", "it", "I.T.", "Information Technology", "Info Tech"—making aggregation impossible. With a Choice or Reference field, you have one consistent value and clean analytics that are easy to interpret and make decisions against.

Source: ServiceNow Community - Field Grouping Behavior

Layman Translation

String field: "Free-text box where users type anything. You cannot effectively report on these values."
Choice/Reference field: "Dropdown menu where everyone picks from the same list. You can report on these fields, and values can be shared across multiple forms to prevent duplicate data entry."

MANDATORY FIELD CONSTRAINTS: BOOLEAN LIMITATIONS

Technical Constraint

Boolean (True/False) fields cannot be effectively mandatory. The root cause is simple: these fields always contain a value (true or false), so the mandatory flag becomes meaningless. The system considers the field "filled in" whether checked or unchecked.

Database storage: Boolean fields are stored as VARCHAR strings containing "0" (false) or "1" (true). ServiceNow conceptually maps this to MySQL's tinyint(1) data type for developer understanding, but the actual database implementation stores these as string values.

Sources: ServiceNow Official Blog - Boolean Field Behavior, ServiceNow Community - Database String Storage

Scripting Complexity: Client vs Server value Mismatch

Boolean fields create scripting challenges because getValue() returns different string representations depending on context:

Database: Stores STRING "0" or "1"
Server-side (GlideRecord): gr.getValue('boolean_field') returns STRING "0" or "1" (matches database)
Client-side (g_form): g_form.getValue('boolean_field') returns STRING "true" or "false" (transformed for UI)

Solutions by context:

Client scripts: Use g_form.getBooleanValue() to get actual Boolean instead of string
Server scripts: Use dot-walking with double-bang (!!gr.boolean_field) for Boolean coercion, or compare directly against "0" or "1" strings
Challenge: Same getValue() method, different string formats depending on client vs server context

Sources: GitHub - Boolean getValue Behavior, ServiceNow Developer Article - getBooleanValue

Tactical Solution

Instead of a Boolean mandatory field, use a Choice field with three values: "-- None --", "Yes", "No". This provides:

Actual mandatory validation that works
Consistent string values across client and server contexts
Eliminates the client/server getValue() string format mismatch

Layman Translation

Problem: "Checkboxes are always checked or unchecked—you can't force someone to make a selection. Plus, when you check the value in code, the database stores it as text '0' or '1', the server gives you '0' or '1', but the client interface gives you 'true' or 'false'—all different representations of the same thing."
Solution: "Use a dropdown with blank/yes/no options. Same clear text values everywhere in the code, and the system can actually require the user to make a choice."

Reference Tables vs. Choice Lists: Change Management Considerations

Static Choice Lists

Use case: Values that NEVER change (e.g., US states, months of the year, cardinal directions)

Update process: A developer must create an update set, migrate it through development, test, and production environments—a process that can take days or weeks, depending on your change/release management policies.

Risk: Every value change requires IT intervention, deployment cycles, and potential production freeze windows.

Dynamic Reference Tables

Use case: Values that change periodically based on business operations

Example scenarios:

Departments (cmn_department) - organizational reorganizations
Cost centers - fiscal year changes
Vendors - evolving partnerships
Project codes - new strategic initiatives
Locations (cmn_location) - office expansions or closures

Update process: Custom Application super users (think of them as app admins) can update reference table records directly in production. This is a data change, not a code change, so it bypasses the entire development lifecycle.

Source: ServiceNow Community - Catalog Design Best Practices

Reference Table Strategy

Leverage OOTB tables: Use existing tables when appropriate (cmn_department for departments, cmn_location for locations, core_company for companies)

Create custom tables: Build new reference tables when no out-of-box equivalent exists for your specific business need

CRITICAL—Always include an "Active" field (Boolean type) on custom reference tables:

Allows for inactivating values that are no longer used
Maintains a complete audit trail of historical values
Prevents selection going forward without deleting data and losing history
Example: A department is eliminated in a reorganization—inactivate it rather than delete it, preserving the historical context for all records that referenced it

Anti-pattern to avoid: Never create a reference field pointing directly to the sys_choice table. The ServiceNow platform can drop and recreate this table for performance optimization, which will orphan all your references.

Source: ServiceNow Developer Blog - Choice Table Reference Warning

Reporting Constraint: List Fields

List fields (fields that allow multiple reference selections) cannot support quick out-of-box grouping or slicing in reports. Aggregating data from List fields (of reference values) requires scripted reports or custom aggregation logic, which adds development overhead.

Choice fields, by contrast, support native grouping and slicing without requiring any scripting.

Decision factor: If your reporting requirements include grouping by multiple selections, carefully evaluate whether a List field is appropriate or if an alternative data model would better serve analytics needs.

Source: ServiceNow Community - Field Grouping Capabilities

Database Storage Reality

Here's a critical technical detail that explains many ServiceNow behaviors: All ServiceNow data is stored as VARCHAR (string) in the underlying database.

Field types like Integer, Boolean, Date, and Reference are an abstraction layer over string storage:

Reference fields: Store 32-character GUID strings (sys_id values)
Choice fields: Store string values from the sys_choice table
Integer fields: Store numeric values as strings
Date fields: Store date/time as formatted strings
Boolean fields: Store "0" or "1" as strings in database (displayed as checkboxes in UI)

Implication: This is why all getValue() operations return strings—because the database literally contains strings, regardless of what field type abstraction sits on top.

Layman Translation

Choice list: "Values are hardcoded in the application. Changing them requires a programmer and a deployment cycle. But they're easy to slice and dice in reports."
Reference table: "Values live in a separate list that business users can update themselves, complete with history tracking through the Active field. Single selections report easily; multiple selections need custom scripting for reporting."
Database reality: "Everything is stored as text behind the scenes. ServiceNow makes it look like numbers, dates, and checkboxes in the interface, but it's all text in the database."

Common Field Types for Custom Scoped Applications

Understanding the full range of available field types ensures you select the right tool for each data capture requirement:

Field Type	Database Storage	Use Case	Key Considerations
String	VARCHAR	Free-text input, names, descriptions	Max 40-255 chars, not normalized, cannot report effectively
Choice	String (with sys_choice link)	Fixed dropdown values that may change	Normalized, reportable, shareable across fields
Reference	32-char GUID string	Link to another table record	Normalized, reportable, shareable, supports Active field pattern
List	Comma-separated GUID strings	Multiple selections from reference table	Cannot group/slice in reports without scripting
True/False	String "0" or "1"	Simple binary state	Cannot be mandatory, client/server scripting mismatch
Integer	String	Whole numbers, counts, quantities	Cannot convert to/from Decimal after creation
Decimal	String (precision varies)	Currency, precise measurements	Max length determines decimal precision
Date	String (formatted)	Calendar date without time	Timezone-agnostic
Date/Time	String (formatted)	Timestamp with time component	Timezone-aware, use for time-sensitive records
Duration	String	Time elapsed (work hours, SLA time)	System-calculated or manually entered
Email	String with validation	Email addresses	Auto-formats, validates structure
URL	String with validation	Web links, external references	Creates clickable hyperlinks in forms
Journal	Journal entry	Timestamped audit trail of changes	Cannot edit historical entries once saved

Sources: Medium - Custom Tables, ServiceNow Community - Location Table

Field Type Decision Matrix

Use this tactical reference when creating each field in your application:

If you need...	Use this type	Rationale
Free-text input	String	User needs flexibility, reporting not required
Dropdown with 2-10 fixed values that NEVER change	Choice	Simple, normalized, reportable, no maintenance
Dropdown with values that change periodically	Reference (to custom table with Active field)	Self-service updates, audit trail, business autonomy
Yes/No with "not answered" state	Choice (with --None--)	Mandatory validation works, no scripting complexity
Multiple selections from same list	List (Reference)	Normalized, prevents duplication, scripted reporting
Checkbox for binary state (not mandatory)	True/False	Simple state tracking when mandatory not required
Aggregated reporting required	Choice or Reference	Normalized data enables grouping and slicing
Whole numbers, counts	Integer	Proper numeric storage, calculations
Currency or precise measurements	Decimal	Financial calculations, specify precision
Calendar date only	Date	No time component, timezone-agnostic
Timestamp with time	Date/Time	Time-sensitive records, timezone-aware
Time elapsed or duration	Duration	SLA tracking, work hours calculation
Contact information	Email	Built-in validation and formatting
External links	URL	Clickable hyperlinks in interface
Audit trail of changes	Journal	Immutable timestamped history

Tactical Recommendations

Planning Phase

Before creating any field, ask stakeholders three critical questions:

"How often will these values change?" — Drives choice between static Choice list and dynamic Reference table
"Will analytics need to slice data by this field?" — Determines if normalization is required
"Who maintains these values long-term?" — Identifies whether business users need direct update access

Implementation Phase

Execute these steps for every custom reference table:

Document data type rationale in technical design documentation
For reference tables: Always include Active field (Boolean type, default true)
For reference tables: Set up delegated administration roles so business users can manage values
Test reporting scenarios in sub-production environments before go-live
Validate Boolean field scripting on both client and server sides if used

Communication Framework

Translate technical decisions into business value:

To business stakeholders: "Reference tables with Active fields mean you control your own values with complete audit history—no waiting for IT."
To developers: "Choice and Reference fields optimize for normalized reporting and data reusability. Everything is strings in the database, but the abstraction layer matters for how we query and display."

Conclusion

Data type selection is strategic architecture, not cosmetic UI design. The correct choice enables scalable applications, business autonomy for value management, actionable analytics, and maintainable data models. The incorrect choice creates technical debt that compounds with every record created.

Apply this decision matrix before creating each field in your next scoped application. Your future self—and your business stakeholders—will thank you when reports work seamlessly and value updates don't require deployment cycles.

Sources

All information verified against current ServiceNow documentation and community resources: