ServiceNow Field Labels: Customize for Clarity & Better UX






Mastering Field Labels in ServiceNow: A Developer’s Guide to Glide APIs


Mastering Field Labels in ServiceNow: A Developer’s Guide to Glide APIs

Ever wondered what makes a ServiceNow form intuitive, or how changes you script under the hood translate into a seamless user experience? The unsung heroes are often field labels. While users interact with a friendly label like “Short Description” or “Assigned To,” behind the scenes, developers are manipulating fields through powerful APIs. This article dives deep into how you, as a ServiceNow developer, can programmatically interact with these fields, directly and indirectly influencing the labels users see and understand.

We’ll journey through the core Glide APIs, specifically GlideRecord for server-side operations and GlideForm for client-side magic. By understanding how to manipulate the underlying data and the front-end presentation of fields, you gain ultimate control over your ServiceNow instance, ensuring both functionality and exceptional user experience.

The Blueprint: What We’ll Cover

  • Glide API Essentials: A foundational look at why Glide APIs are your best friend in ServiceNow.
  • Server-Side Power with GlideRecord: Diving into CRUD operations and advanced querying, focusing on how these manipulate the data fields behind the labels.
  • Client-Side Control with GlideForm: Mastering UI interactions, making fields mandatory, visible, or read-only, and how these directly impact what users see through field labels.
  • Practical Exercises & Real-World Scenarios: Hands-on examples to solidify your understanding.
  • Troubleshooting & Best Practices: Navigating common pitfalls and writing efficient, maintainable code.
  • Interview Edge: How these skills prepare you for success.

Unpacking Glide APIs: Your Toolkit for ServiceNow Customization

ServiceNow isn’t just a platform; it’s a canvas for customization. And at the heart of nearly all custom development lies the Glide API. Think of Glide APIs as a robust set of predefined JavaScript classes and methods that allow you to interact with the platform’s core functionalities and data without resorting to raw SQL or complex browser DOM manipulations.

These APIs provide the flexibility to:

  • Modify default application behavior.
  • Customize existing functionalities to fit unique business processes.
  • Perform database operations (Create, Read, Update, Delete – CRUD) in a secure and platform-agnostic way.
  • Manipulate elements on forms, lists, and other UI components.

Essentially, if you need to go beyond configuration and introduce dynamic, intelligent behavior, Glide APIs are your gateway.

Client-Side vs. Server-Side: The Two Sides of the Glide Coin

The world of ServiceNow scripting is broadly divided into two realms: Client-Side and Server-Side. Each has its own set of Glide APIs, designed for specific purposes and execution environments.

Client-Side (Browser Execution)Server-Side (Instance Execution)
GlideForm (g_form)GlideRecord
GlideUser (g_user)GlideSystem (gs)
GlideAjaxGlideDate
GlideDialogWindowGlideDateAndTime
GlideListGlideAggregation
GlideMenuGlideElement
…and many more for UI interaction…and many more for background processing

When we talk about field labels, client-side APIs like GlideForm directly impact what a user sees in their browser – whether a field is visible, mandatory, or read-only. Server-side APIs, especially GlideRecord, manage the underlying data that these labels represent, ensuring data integrity and business logic are enforced even when a field’s visual properties change.

GlideRecord: The Server-Side Powerhouse for Data Interaction

If you’re interacting with data in ServiceNow scripts, chances are you’re using GlideRecord. This powerful server-side API is the cornerstone of almost all data manipulation on the platform. It’s essentially ServiceNow’s custom ORM (Object-Relational Mapping) layer, allowing you to perform database CRUD (Create, Read, Update, Delete) operations using JavaScript objects and methods, abstracting away the complexities of direct SQL queries.

Think of it this way: instead of writing SQL like SELECT * FROM incident WHERE priority = 1;, you write JavaScript that’s more readable and ServiceNow-aware: var inc = new GlideRecord('incident'); inc.addQuery('priority', 1); inc.query();. This not only simplifies development but also enhances security and ensures platform best practices are followed.

Key Characteristics of GlideRecord:

  • Server-Side Execution: Runs in Business Rules, Script Includes, Fix Scripts, Workflows, UI Actions (server-side), and Scheduled Jobs.
  • Database Interaction: Facilitates CRUD operations on tables, managing both rows (records) and columns (fields).
  • SQL Generation: Implicitly translates your JavaScript methods into optimized SQL queries for the underlying database.
A Crucial Note on Data Integrity: Always, and we mean always, test your GlideRecord scripts on a non-production instance first. An improperly constructed query or incorrect field name can lead to unexpected behavior, including incorrect data retrieval, or worse, accidental data loss when using insert(), update(), or deleteRecord(). Your data is precious!

How GlideRecord Works: Bridging JavaScript and Your Database

Conceptually, GlideRecord acts as an intelligent intermediary. You express your data requirements in JavaScript, and GlideRecord takes care of translating those into the appropriate SQL commands that the ServiceNow database understands. This abstraction layer is a key component of the platform’s architecture.

[Imagine a simple diagram here: JavaScript/Scripting Layer -> GlideRecord API -> SQL Query Generation -> ServiceNow Database]

Common GlideRecord Methods: Your Data Command Center

The list of GlideRecord methods is extensive, covering everything from simple queries to complex data manipulation. Here’s a look at some of the most frequently used methods, along with explanations and practical examples.

CategoryMethodDescription & Field Label Relevance
Queryingquery()Executes the query built with addQuery(), addEncodedQuery(), etc. This fetches the records whose fields match your criteria.
addQuery(field, value)
addQuery(field, operator, value)
Adds a query condition. You specify the backend field name (e.g., ‘priority’), and the operator/value. The user interacts with the label ‘Priority’ on the form.
addEncodedQuery(query_string)Adds an encoded query string, useful for complex or pre-built conditions. Still operates on backend field names.
addActiveQuery() / addInactiveQuery()Shorthands for addQuery('active', true) or false. Directly affects the ‘Active’ field, which has an ‘Active’ label.
next() / hasNext()Iterates through query results. Allows you to access each record’s fields.
get(sys_id_or_field, value)Retrieves a single record by its sys_id or a unique field’s value.
setLimit(num)Limits the number of records returned by the query.
orderBy(field) / orderByDesc(field)Sorts the query results based on a specified field’s value (ascending/descending).
getRowCount()Returns the total number of records matched by the query.
getEncodedQuery()Retrieves the current encoded query string for the GlideRecord object. Useful for debugging.
Data AccessgetValue(field)Retrieves the actual (backend) value of a field.
getDisplayValue(field)Retrieves the display value of a field (what the user sees, e.g., “High” instead of “2” for priority). This is often directly related to the field label context.
getLabel()Returns the label of the current table or a specified field. This is a direct way to programmatically access the user-friendly name associated with a field or table.
getElement(field)Returns a GlideElement object for a specified field, allowing access to its properties (e.g., label, mandatory status).
getTableName() / getRecordClassName()Returns the name of the table associated with the GlideRecord object.
getUniqueValue()Returns the sys_id of the current record.
Manipulationinitialize() / newRecord()Prepares a new empty record for insertion. All fields are blank initially.
setValue(field, value)Sets the value of a specific field on the current record. This is how you populate fields before inserting or updating.
insert()Inserts the current record into the database.
update() / updateMultiple()Updates the current record or multiple records matching the query.
deleteRecord() / deleteMultiple()Deletes the current record or multiple records.
autoSysFields(false)Disables the automatic update of system fields (e.g., sys_updated_on, sys_updated_by).
setWorkflow(false)Prevents business rules from running during an update or insert.
Validation/ACLsisValid() / isValidField(field)Checks if the table/field exists.
isNewRecord() / isValidRecord()Checks if the record is new or if a valid record was returned by a query.
canCreate(), canRead(), canWrite(), canDelete()Determines if the current user has ACL permissions for the specified operation.
Pro Tip: Most of these server-side scripts are best tested in the Script – Background module or in a dedicated Fix Script. For quick debugging, gs.print() and gs.info() are your best friends.

GlideRecord in Action: Practical Exercises (and where labels fit in)

1. Basic Output: Your “Hello World” for Server Scripts

Before diving into records, let’s ensure we can see output. This is fundamental for debugging any script manipulating fields.

gs.print('Welcome to ServiceNow Academy');
gs.info('Welcome to ServiceNow Academy');
Result → Console output: “Welcome to ServiceNow Academy”

2. Simple Arithmetic

A quick reminder that you’re writing JavaScript!

var a = 10;
var b = 20;
var c = a + b;
gs.print(a + b); // Or gs.print(c);
Result → Console output: 30

3. Working with query() and next(): Listing Field Values

This is your bread and butter for retrieving multiple records and accessing their fields. When you print inc.number, you’re accessing the data associated with the ‘Number’ field, whose label the user sees.

var inc = new GlideRecord('incident'); // Initialize GlideRecord for the 'incident' table
inc.query(); // Execute the query to retrieve all incidents
while (inc.next()) { // Loop through each incident record found
    gs.print(inc.number); // Print the 'Number' field's value
}
Result → Prints all incident numbers (e.g., INC0000001, INC0000002, …)

4. Filtering with addQuery(): Targeting Specific Fields

addQuery() allows you to filter records based on field values. Here, we’re targeting the ‘Priority’ field (which has a label of “Priority” on the form).

var inc = new GlideRecord('incident');
inc.addQuery('priority', '1'); // Find records where the 'priority' field's value is 1
inc.query();
while (inc.next()) {
    gs.print(inc.number); // Print the number of matching incidents
}
Result → Prints incident numbers for all Priority 1 tickets.

5. Multiple Queries with addQuery(): Chaining Conditions

You can combine multiple addQuery() statements to create more complex filters. This is still interacting with specific fields, whose labels guide users in understanding the data.

var inc = new GlideRecord('incident');
inc.addQuery('active', true);           // Condition 1: 'Active' field is true
inc.addQuery('priority', '1');          // Condition 2: 'Priority' field is 1
inc.addQuery('category', 'software');   // Condition 3: 'Category' field is 'software'
inc.query();
while (inc.next()) {
    gs.print(inc.number);
}
Result → Prints incident numbers meeting all three conditions.

6. Power of addEncodedQuery(): Complex Field Filtering

For even more intricate filters across many fields, addEncodedQuery() is invaluable. You can build these queries visually on a list view, which naturally reflects the field labels, then copy the generated encoded query string.

Steps to get an Encoded Query:

  1. Navigate to a list (e.g., Incident list).
  2. Apply your desired filters using the condition builder (e.g., “Active is true AND Priority is 1 AND Category is Software”).
  3. Right-click the filter breadcrumbs and select “Copy query.”
var inc = new GlideRecord('incident');
inc.addEncodedQuery('active=true^category=software^priority=1'); // Using the copied encoded query
inc.query();
while (inc.next()) {
    gs.print(inc.number);
}

You can also store the encoded query in a variable for cleaner code:

var ecq = 'active=true^category=software^priority=1';
var inc = new GlideRecord('incident');
inc.addEncodedQuery(ecq);
inc.query();
while (inc.next()) {
    gs.print(inc.number);
}
Result → Prints incident numbers matching the complex encoded query.

7. Advanced Query Operators for Field Values

addQuery() supports various operators, allowing precise control over how field values are matched.

  • Comparison Operators: =, !=, >, >=, <, <=
  • String Operators (case-insensitive for database search): IN, NOT IN, STARTSWITH, ENDSWITH, CONTAINS, DOES NOT CONTAIN

Example: Active and Priority <= 2

var inc = new GlideRecord('incident');
inc.addActiveQuery(); // Shorthand for active=true
inc.addQuery('priority','<=','2'); // Find records where 'priority' field is 1 or 2
inc.query();
while (inc.next()) {
    gs.print(inc.number);
}
Result → Prints incident numbers for Critical (1) and High (2) priority active tickets.

Example: Priority <= 2 AND Short Description Contains "SAP"

var inc = new GlideRecord('incident');
inc.addActiveQuery();
inc.addQuery('priority','<=','2');
inc.addQuery('short_description','CONTAINS','SAP'); // Look for 'SAP' in the 'Short description' field
inc.query();
while (inc.next()) {
    gs.print(inc.number + ' - ' + inc.short_description);
}
Result → Prints active incidents with Priority 1 or 2 whose short description contains "SAP".

Example: Category IN ['software', 'hardware']

var cat = ['software', 'hardware']; // Array of values for the 'Category' field
var inc = new GlideRecord('incident');
inc.addQuery('category', 'IN', cat); // Find records where 'category' field is 'software' OR 'hardware'
inc.query();
while (inc.next()) {
    gs.print(inc.getValue('number') + ' - ' + inc.getValue('short_description'));
}
Result → Prints incidents categorized as Software or Hardware.

8. `addActiveQuery()` and `addInactiveQuery()`: Simplifying Active Field Filters

These methods are convenient wrappers for filtering on the 'active' field (which users typically see labeled as "Active" or implied by state).

var inc = new GlideRecord('incident');
inc.addActiveQuery(); // Equivalent to inc.addQuery('active', true);
inc.addQuery('priority', '1');
inc.query();
while (inc.next()) {
    gs.info(inc.number);
}
Result → Prints active, Priority 1 incident numbers.
var inc = new GlideRecord('incident');
inc.addInactiveQuery(); // Equivalent to inc.addQuery('active', false);
inc.addQuery('priority', '1');
inc.query();
while (inc.next()) {
    gs.print(inc.number);
}
Result → Prints inactive (e.g., Closed) Priority 1 incident numbers.

9. `orderBy()` and `orderByDesc()`: Sorting Your Field Data

Control the order in which your query results (and their fields) are returned. This is crucial for reports or displaying recent items first.

var inc = new GlideRecord('incident');
inc.addQuery('priority', '1');
inc.orderBy('short_description'); // Order results by 'Short description' field ascending
inc.query();
while (inc.next()) {
    gs.print(inc.number + ' - ' + inc.short_description);
}
Result → Prints Priority 1 incidents sorted by their Short Description.
var inc = new GlideRecord('incident');
inc.addQuery('priority', '1');
inc.orderByDesc('short_description'); // Order results by 'Short description' field descending
inc.query();
while (inc.next()) {
    gs.print(inc.number + ' - ' + inc.short_description);
}
Result → Prints Priority 1 incidents sorted by Short Description in reverse alphabetical order.

10. `setLimit()`: Managing Your Result Set

When you only need a few records, setLimit() is your friend for performance optimization.

var inc = new GlideRecord('incident');
inc.addQuery('priority', '1');
inc.orderByDesc('sys_created_on'); // Get the most recent ones
inc.setLimit(5); // Only retrieve the first 5 records
inc.query();
while (inc.next()) {
    gs.print(inc.number + ' - ' + inc.short_description);
}
Result → Prints the 5 most recently created Priority 1 incidents.

11. `get()` Method: Fetching a Single Record by Field Value or Sys_ID

This is often used to retrieve a specific record when you know its unique identifier (like Number or Sys_ID).

var inc = new GlideRecord('incident');
inc.get('number','INC0009005'); // Fetch incident with 'number' field value 'INC0009005'
gs.print(inc.sys_id);
Result → Prints the sys_id corresponding to INC0009005.
var inc = new GlideRecord('incident');
inc.get('6007e9c5c0a801650085a6767571f3b8'); // Fetch record by its sys_id
gs.print(inc.number);
Result → Prints the incident number for the given sys_id.

12. `getRowCount()` and `getTableName()`: Understanding Your Query and Table

These methods help you get meta-information about your query or the table you're working with, which can be useful for dynamic scripting or logging.

var inc = new GlideRecord('incident');
inc.query();
gs.print('Total incidents: ' + inc.getRowCount()); // Get count of all incidents
Result → Prints the total number of records in the Incident table.
var userGR = new GlideRecord('sys_user');
userGR.addQuery('active', true); // Filter for active users
userGR.query();
gs.print('Active users count: ' + userGR.getRowCount());
Result → Prints the count of active users.
var gr = new GlideRecord('change_request');
gs.print('Working on table: ' + gr.getTableName());
Result → Prints "Working on table: change_request".

13. `getValue()` vs. `getDisplayValue()`: Raw vs. User-Friendly Field Data

This is crucial for understanding how field values are stored versus how they are presented to the user. For fields like 'Priority' or 'State', the backend value might be a number, while the display value is a human-readable string – the field label often hints at this.

var inc = new GlideRecord('incident');
inc.addQuery('priority', '1');
inc.setLimit(1); // Just get one record for the example
inc.query();
if (inc.next()) {
    gs.print('Priority (raw value): ' + inc.getValue('priority'));
    gs.print('Priority (display value): ' + inc.getDisplayValue('priority'));
    // Or directly using dot-walking for display value on reference/choice fields
    gs.print('Caller (display value via dot-walking): ' + inc.caller_id.getDisplayValue());
}
Result →

Priority (raw value): 1
Priority (display value): Critical
Caller (display value via dot-walking): Abel Tuter

14. getLabel(): Programmatically Accessing Field Labels

Finally, the method explicitly for labels! While many GlideRecord operations deal with the field's backend name, there are times you need its user-facing label. This is particularly useful for dynamic messaging, internationalization, or generating user-friendly reports.

var inc = new GlideRecord('incident');
inc.initialize(); // Or query an existing record
// Get the label for a specific field on the incident table
var shortDescriptionLabel = inc.getElement('short_description').getLabel();
gs.print('The label for short_description is: ' + shortDescriptionLabel);

// Get the label of the current table itself
var incidentTableLabel = inc.getLabel();
gs.print('The label for the incident table is: ' + incidentTableLabel);

// Dynamic message using a field label
inc.category = 'network';
inc.short_description = 'Server outage';
if (inc.category == 'network') {
    var categoryFieldLabel = inc.getElement('category').getLabel();
    gs.print('Alert: ' + categoryFieldLabel + ' is ' + inc.getDisplayValue('category') + ' for ' + inc.number);
}
Result →

The label for short_description is: Short description
The label for the incident table is: Incident
Alert: Category is Network for [Incident Number]

Interview Insight: Knowing getLabel() demonstrates a nuanced understanding of ServiceNow's data model and user experience, which is a big plus in developer interviews. It shows you can think beyond just backend names.

15. `initialize()`, `setValue()`, and `insert()`: Creating New Records and Populating Fields

This sequence is fundamental for creating new records and setting their field values. Here, you define what will appear under the corresponding field labels once the record is saved.

var inc = new GlideRecord('incident');
inc.initialize(); // Prepares a new, empty incident record
inc.category = 'network'; // Set 'Category' field value
inc.setValue('short_description', 'Critical VPN Issue - New Record'); // Set 'Short description' field value using setValue()
inc.priority = '1'; // Set 'Priority' field value
inc.insert(); // Save the new record to the database
gs.print('Created new incident: ' + inc.number);
gs.print('Category: ' + inc.category + ', Short Description: ' + inc.short_description);
Result → Creates a new incident (e.g., INC0010015) and prints its number and field values.

16. `update()` and `updateMultiple()`: Modifying Existing Records

These methods let you change field values on existing records. An update might change what a user sees under a field's label on a form or list.

Single Record Update:

var inc = new GlideRecord('incident');
inc.get('number', 'INC0000057'); // Fetch a specific incident
if (inc.isValidRecord()) {
    inc.setValue('state', 2); // Set 'State' field to "In Progress" (value 2)
    inc.update(); // Save the changes
    gs.print('Updated incident ' + inc.number + ' to state: ' + inc.getDisplayValue('state'));
} else {
    gs.print('Incident INC0000057 not found.');
}
Result → Updates INC0000057's 'State' field.

Multiple Records Update:

var inc = new GlideRecord('incident');
inc.addQuery('category', 'hardware'); // Find all incidents where 'Category' is hardware
inc.setValue('category', 'software'); // Change their 'Category' field to software
inc.updateMultiple(); // Apply the update to all matched records
gs.print('Updated multiple incidents: Changed category from Hardware to Software.');
Result → All incidents previously categorized as 'hardware' will now be 'software'.

17. `deleteRecord()` and `deleteMultiple()`: Removing Records

Use these methods with extreme caution! They permanently remove records from your database. There's no undo.

Single Record Delete:

var inc = new GlideRecord('incident');
inc.get('number', 'INC0010013'); // The incident you wish to delete
if (inc.isValidRecord()) {
    inc.deleteRecord();
    gs.print('Deleted incident: ' + inc.number);
} else {
    gs.print('Incident INC0010013 not found.');
}
Result → Incident INC0010013 is deleted.

Multiple Records Delete:

var inc = new GlideRecord('incident');
inc.addQuery('priority', '4'); // Find all incidents with 'Priority' 4 (Low)
inc.query();
var deletedCount = inc.getRowCount(); // Get count before deletion
inc.deleteMultiple();
gs.print('Deleted ' + deletedCount + ' incidents with Priority 4.');
Result → All incidents with Priority 4 are deleted.

18. `canCreate()`, `canRead()`, `canWrite()`, `canDelete()`: ACL Validation

These methods are crucial for building secure applications, checking if the current user has the necessary Access Control List (ACL) permissions to interact with records and their fields.

var inc = new GlideRecord('incident');
gs.print('Can create incident: ' + inc.canCreate());
gs.print('Can read incident: ' + inc.canRead());
gs.print('Can write incident: ' + inc.canWrite());
gs.print('Can delete incident: ' + inc.canDelete());
Result → Prints true/false based on the running user's ACLs for the Incident table.

19. `autoSysFields(false)` and `setWorkflow(false)`: Bypassing System Updates and Business Rules

These methods are powerful but should be used sparingly, primarily for data migrations or specific integrations where you don't want standard platform behaviors (like updating "Updated by" fields or running Business Rules) to kick in. This affects how changes to fields are recorded and processed.

Important:

  • autoSysFields(false) may not work in scoped applications.
  • setWorkflow(false) will bypass all other Business Rules, potentially leading to data inconsistencies if not carefully managed.
var inc = new GlideRecord('incident');
inc.addQuery('state', 1); // Query for New incidents
inc.query();
while (inc.next()) {
    inc.autoSysFields(false); // Do not update 'sys_updated_on', 'sys_updated_by', etc.
    inc.setWorkflow(false);   // Do not run Business Rules
    inc.setValue('state', 2); // Set 'State' field to "In Progress"
    inc.update();
}
gs.print('Incidents updated without system field or workflow changes.');
Result → Updates incident states, but system fields (e.g., Updated by) will not change, and no Business Rules related to the update will fire.

20. `addJoinQuery()`: Complex Relational Queries Across Fields

This method allows you to query records based on conditions met in a related table, linking fields between them. This is how you find, for example, Problems related to specific Incidents.

var prob = new GlideRecord('problem');
// Join the 'problem' table with the 'incident' table
// where 'problem.opened_by' field matches 'incident.caller_id' field
prob.addJoinQuery('incident', 'opened_by', 'caller_id');
prob.query();
while (prob.next()) {
    gs.print(prob.number + ' (opened by ' + prob.opened_by.name + ') has related incident(s)');
}
Result → Displays problem numbers where the problem's 'Opened by' field matches an incident's 'Caller' field.

GlideForm (g_form): Your Client-Side Maestro for UI and Field Labels

While GlideRecord handles the backend data, GlideForm is your toolkit for client-side interactions, directly impacting what the user sees and experiences on a form. The global object g_form exposes these methods, making it incredibly powerful for customizing UI behavior, especially in Client Scripts and Catalog Client Scripts.

When you manipulate a field with g_form, you're directly affecting its presentation: its visibility, its mandatory status, its value, and implicitly, how its label guides the user's interaction.

Key Characteristics of GlideForm:

  • Client-Side Execution: Runs directly in the user's browser.
  • UI Manipulation: Primarily used to change the default behavior and appearance of fields on the current form.
  • g_form Object: All GlideForm methods are accessed via the global g_form object.
  • Validation & Interaction: Ideal for real-time form validation, dynamically showing/hiding fields, setting values, and displaying messages.
Best Practice Alert: While g_form methods are powerful, always consider if a UI Policy or Data Policy can achieve the same result. UI Policies are declarative (no code) and generally perform better and are easier to maintain for simple UI manipulations (mandatory, visible, read-only). Use client scripts with g_form for more complex logic that UI Policies can't handle.

Common GlideForm Methods: Sculpting the User Experience

MethodDescription & Field Label Relevance
setValue(fieldName, value)Sets the value of a field. This updates the content displayed next to the field's label.
getValue(fieldName)Retrieves the current value of a field.
setDisabled(fieldName, isDisabled)
setReadOnly(fieldName, isReadOnly)
Makes a field read-only. The field's label will appear next to the greyed-out or non-editable input.
setMandatory(fieldName, isMandatory)Makes a field mandatory. The field's label will gain a visible red asterisk, prompting user input.
setDisplay(fieldName, isVisible)Hides or shows a field and its label, collapsing the space it occupied.
setVisible(fieldName, isVisible)Hides or shows a field and its label, but retains the space it occupied (less common).
addInfoMessage(message)
addErrorMessage(message)
Displays informative or error messages to the user, often related to field validation.
showFieldMsg(fieldName, message, type)
hideFieldMsg(fieldName, clearAll)
Displays or hides a message directly below a specific field's label, providing context-sensitive feedback.
getControl(fieldName)
getElement(fieldName)
Gets a reference to the HTML element representing the field, allowing advanced DOM manipulation.
getLabelOf(fieldName)Returns the user-friendly label of a specific field on the form. (Note: g_form.getLabelOf() is a standard method, complementing GlideRecord's getElement().getLabel()).
getTableName()
getUniqueValue()
isNewRecord()
Retrieves form-level information like the table name, current record's sys_id, or if it's a new record.
save() / submit()Programmatically saves or submits the form.

GlideForm in Action: Client-Side Exercises

To run these examples, navigate to an Incident form in ServiceNow, open an existing record, and then press Ctrl+Shift+J (or Cmd+Shift+J on Mac) to open your browser's JavaScript console. Type the commands directly into the console and hit Enter.

1. `getValue()` and `setValue()`: Reading and Writing Field Values

Directly interact with the data shown alongside field labels.

// Get the value of the 'category' field
alert(g_form.getValue('category'));

// Set the value of the 'category' field to 'hardware'
g_form.setValue('category', 'hardware');
alert('Category is now: ' + g_form.getValue('category'));

2. `setDisabled()` / `setReadOnly()`: Making Fields Non-Editable

Gray out a field, preventing user input. The label remains, but the field becomes unresponsive.

// Make the 'category' field read-only
g_form.setDisabled('category', true); // or g_form.setReadOnly('category', true);
alert('Category field is now read-only.');
Best Practice: For making fields read-only based on conditions, a UI Policy is often preferred for maintainability and performance.

3. `setMandatory()`: Requiring User Input for a Field

Visually marks a field with a red asterisk, indicating it must be filled. This directly impacts the user's perception of the field's label.

// Make the 'category' field mandatory
g_form.setMandatory('category', true);
alert('Category field is now mandatory.');
Best Practice: Use a UI Policy or Data Policy for making fields mandatory based on conditions.

4. `setDisplay()` and `setVisible()`: Controlling Field Visibility

These methods allow you to dynamically show or hide fields and their labels on a form.

// Hide the 'business_service' field (and its label) and collapse its space
g_form.setDisplay('business_service', false);
alert('Business Service field is hidden (space collapsed).');

// Hide the 'subcategory' field (and its label) but maintain its space
g_form.setVisible('subcategory', false);
alert('Subcategory field is hidden (space maintained).');
Best Practice: For hiding/showing fields, a UI Policy is usually the best approach.

5. `isMandatory()`: Checking Field Status

Useful for conditional logic where you need to know if a field is currently mandatory.

// Check if the 'category' field is mandatory
var isCatMandatory = g_form.isMandatory('category');
alert('Is category field mandatory? ' + isCatMandatory);

6. `showFieldMsg()` and `getLabelOf()`: Contextual Feedback using Labels

Combining these allows you to give users precise feedback related to a specific field, using its actual label for clarity.

// Get the label for the 'short_description' field
var sdLabel = g_form.getLabelOf('short_description');
alert('Label for short_description: ' + sdLabel);

// Display an error message directly under the 'short_description' field's label
g_form.showFieldMsg('short_description', 'Please provide more detail for the ' + sdLabel + '.', 'error');
alert('Field message shown for Short Description.');

Troubleshooting Common Field & Label Issues

  • Incorrect Field Name: A common culprit! Ensure you're using the correct backend field name (e.g., `short_description`, not `Short Description`). Double-check in the field dictionary.
  • ACLs (Access Control Lists): If your server-side script isn't retrieving/updating data, it might be an ACL issue. The user context running the script might not have the necessary permissions. Test with `canRead()`, `canWrite()`, etc.
  • UI Policy vs. Client Script Conflicts: If a field isn't behaving as expected client-side, check for conflicting UI Policies or other Client Scripts that might be overriding your logic (e.g., one script makes a field mandatory, another makes it read-only).
  • Cache Issues: Sometimes, browser or instance cache can cause unexpected behavior. Clear your browser cache or perform a cache flush (`cache.do` for instance cache).
  • Execution Order: Client Scripts and Business Rules execute in a specific order. Ensure your script runs at the appropriate time (e.g., `onLoad` vs. `onChange` for client scripts, `before` vs. `after` for business rules).
  • Scoped Applications: Be aware of API differences and restrictions when working in scoped applications (e.g., `autoSysFields(false)` limitations).
  • Performance: Excessive GlideRecord queries in loops or complex client scripts can impact performance. Optimize your queries and minimize DOM manipulations.

Field Labels in Your Interview: Demonstrating Expertise

Interviewers often ask questions that test your understanding of how ServiceNow works beyond just configuration. Here's how mastering field labels and Glide APIs can make you shine:

  • "Explain the difference between getValue() and getDisplayValue()." This shows you understand data storage vs. user presentation.
  • "When would you use g_form.setMandatory() versus a UI Policy?" This tests your knowledge of best practices and when to choose code over configuration.
  • "How would you dynamically change a field's label based on a condition?" This is where g_form.getLabelOf() and perhaps other DOM manipulation might come into play, demonstrating advanced client-side skills.
  • "You need to fetch an incident's priority and include its label in a notification. How would you do that?" This probes your ability to use both `getDisplayValue()` and `getLabel()` (possibly `getElement().getLabel()` if you want the actual field label, not just the choice's display value).
  • "Describe a scenario where you would use addEncodedQuery()." Shows efficiency and problem-solving.

By articulating not just *what* these methods do, but *why* they're important for both data integrity and user experience (especially concerning field labels), you position yourself as a thoughtful and proficient ServiceNow developer.

Wrapping Up: Your Journey to ServiceNow Mastery

Working with fields and their labels in ServiceNow is fundamental to building robust, user-friendly applications. From the server-side might of GlideRecord, where you manipulate the core data that labels represent, to the client-side finesse of GlideForm, where you directly sculpt the user interface, you now have a comprehensive understanding of the tools at your disposal.

Keep practicing, keep experimenting, and always remember the impact your code has on the end-user's perception through those seemingly simple but incredibly important field labels. Happy scripting!


Scroll to Top