Glide API Overview: Your Gateway to ServiceNow’s Core

Think of ServiceNow as a massive, intricate city. While you can navigate its streets and visit its buildings through the user interface, Glide APIs are like having a master key, a blueprint, and a toolkit that lets you build new structures, modify existing ones, or even re-route traffic flow. For ServiceNow Developers, Glide APIs are the go-to mechanism for moving beyond default behaviors and truly customizing existing functionality.

At its heart, a Glide Class is a set of pre-built functions and methods that provide a structured way to interact with ServiceNow applications through scripting. Instead of writing complex SQL queries (which, let’s be honest, you can’t directly do in ServiceNow anyway!), Glide APIs allow you to perform database operations, manipulate records, manage users, control UI elements, and much more, all using JavaScript. Each API is a collection of methods, and each method is designed to perform a specific, well-defined operation within the ServiceNow ecosystem.

Mastering these APIs isn’t just about writing code; it’s about understanding the underlying architecture of ServiceNow and how to efficiently and safely interact with it. It’s about transforming a “no-code/low-code” platform into a powerhouse capable of truly unique and powerful solutions.

Types of Glide APIs: Client-Side vs. Server-Side – A Tale of Two Worlds

ServiceNow APIs broadly fall into two categories, reflecting where your script executes: on the user’s browser (client-side) or on the ServiceNow server (server-side). Understanding this distinction is paramount, as it dictates what you can achieve, the performance implications, and the security considerations of your code.

While all these APIs are powerful, today, we’re going to zoom in on the undisputed champion of server-side scripting: GlideRecord, followed by a look at its client-side counterpart, GlideForm.

GlideRecord: The Database Whisperer of ServiceNow

If you’re doing anything significant on the server-side in ServiceNow, you’re going to be using GlideRecord. A lot. It’s not just “most common”; it’s foundational.

What is GlideRecord and Why is it Indispensable?

Imagine you need to fetch a list of all active incidents, update a user’s department, or create a new task. In a traditional database environment, you’d write SQL queries like SELECT * FROM incident WHERE active = true; or UPDATE sys_user SET department = 'IT' WHERE user_name = 'john.doe';. But in ServiceNow, you can’t directly type SQL. This is where GlideRecord swoops in.

GlideRecord is essentially a special Java class (exposed to us through JavaScript) that provides an object-oriented way to interact with the ServiceNow database. It acts as an abstraction layer, allowing you to perform all your CRUD (Create, Read, Update, Delete) operations without ever writing a single line of SQL. Instead, you’ll use intuitive JavaScript methods to build your queries and manipulate records. It intelligently handles both rows and columns in the underlying database, translating your JavaScript commands into efficient SQL behind the scenes.

GlideRecord Architecture and API Mapping: A Behind-the-Scenes Look

Conceptually, the GlideRecord architecture works like this: when you instantiate a GlideRecord object for a specific table (e.g., new GlideRecord('incident')), you’re telling ServiceNow, “Hey, I want to talk to the ‘incident’ table.” As you call methods like addQuery(), orderBy(), or setLimit(), GlideRecord is internally building up an SQL query. When you finally call query(), that SQL query is sent to the database. The results are then retrieved and mapped back into GlideRecord objects, allowing you to iterate through them using methods like next() and access field values directly (e.g., inc.number).

This “API Mapping” effectively means GlideRecord acts as an Object-Relational Mapper (ORM). It bridges the gap between your JavaScript objects (GlideRecord instances) and the relational database tables. You interact with JavaScript objects, and GlideRecord takes care of the complex translation to and from database operations.

A Crucial Note on Best Practices and Troubleshooting

Before we dive into the methods, a vital warning:

Always test your GlideRecord scripts on a non-production instance first! An incorrectly constructed encoded query, an invalid field name, or a logical error in your script can lead to unexpected behavior, performance degradation, or, in severe cases, data loss. Methods like deleteRecord(), deleteMultiple(), update(), and updateMultiple() are incredibly powerful and can irrevocably alter your data. Double-check your conditions, query results, and target fields before deploying to production.

Key Characteristics of GlideRecord:

1. Most Common API: You’ll see it everywhere in server-side scripts.
2. Runs from Server-Side: Executes on the ServiceNow instance, not the user’s browser.
3. Generates SQL Queries: Translates JavaScript commands into optimized SQL.
4. Performs CRUD Operations: The primary tool for creating, reading, updating, and deleting records.

GlideRecord Methods: Your Toolkit for Data Manipulation

The beauty of GlideRecord lies in its rich set of methods. Let’s explore some of the most frequently used and important ones. We’ll group them for easier understanding.

Querying and Retrieving Data (The “Read” in CRUD)

These methods are all about finding the data you need.

query(): Execute Your Search

This is the method that actually sends your constructed query to the database.

var inc = new GlideRecord('incident'); // Instantiate GlideRecord for the 'incident' table
inc.query(); // Execute the query (fetches ALL incidents if no addQuery() is used)
while (inc.next()) { // Loop through the results
    gs.print(inc.number); // Print the number of each incident
}

Result: Prints all incident numbers. This is your basic “SELECT * FROM incident” operation.

addQuery(field, value) or addQuery(field, operator, value): Filtering Your Results

This is how you apply filters, similar to a WHERE clause in SQL. You can use one or two parameters for equality, or three for more complex comparisons.

var inc = new GlideRecord('incident');
inc.addQuery('priority', 1); // Shorthand for 'priority = 1'
inc.query();
while(inc.next()){
    gs.print(inc.number);
}

Result: Prints numbers of all priority 1 incidents.

var inc = new GlideRecord('incident');
inc.addQuery('active', true);           // Query 1: active = true
inc.addQuery('priority', 1);            // Query 2: priority = 1
inc.addQuery('category', 'software');    // Query 3: category = software
inc.query();
while(inc.next()){
    gs.print(inc.number + ' | ' + inc.short_description);
}

Result: Prints incident numbers and short descriptions where all three conditions are met (logical AND).

Interview Relevance: Expect questions on how to fetch specific records and apply filters. Understanding addQuery is fundamental.

addEncodedQuery(encodedQueryString): The Power User’s Filter

When you have complex query conditions with multiple ANDs/ORs, or specific operators, generating them manually can be tedious. ServiceNow’s list views generate an “encoded query” string that you can copy and paste directly into this method. This is a massive time-saver!

var ecq = 'active=true^category=software^priority=1'; // Encoded query copied from a list view
var inc = new GlideRecord('incident');
inc.addEncodedQuery(ecq);
inc.query();
while (inc.next()){
    gs.print(inc.number);
}

Result: Prints all incident numbers matching the encoded query.

Practical Tip: To get an encoded query: go to a list view (e.g., Incidents), apply your filters, right-click on the filter breadcrumbs, and choose “Copy query.”

Operators for addQuery('field', 'operator', 'value'): Beyond Equality

You’re not just limited to =. GlideRecord supports a variety of operators:

• Comparison: =, !=, >, >=, <, <=
• String Matching: STARTSWITH, ENDSWITH, CONTAINS, DOES NOT CONTAIN
• List Membership: IN, NOT IN
• Special: INSTANCEOF (for polymorphic tables)

var inc = new GlideRecord('incident');
inc.addActiveQuery(); // Equivalent to inc.addQuery('active', true);
inc.addQuery('priority','<=',2); // Priority is 1 or 2
inc.addQuery('short_description','CONTAINS','SAP'); // Short description includes 'SAP'
inc.query();
while(inc.next()){
    gs.print(inc.number + ' ' + inc.short_description);
}

Result: Prints active incidents with priority 1 or 2, and 'SAP' in their short description.

addActiveQuery() and addInactiveQuery(): Status Shortcuts

Convenience methods for filtering by the 'active' field.

var inc = new GlideRecord('incident');
inc.addActiveQuery(); // Active = true
inc.addQuery('priority',1);
inc.query();
while (inc.next()){
    gs.info(inc.number);
}

Result: Prints active incidents with priority 1.

var inc = new GlideRecord('incident');
inc.addInactiveQuery(); // Active = false
inc.addQuery('priority=1');
inc.query();
while (inc.next()) {
    gs.print(inc.number);
}

Result: Prints inactive (e.g., Closed) incidents with priority 1.

next() and hasNext(): Iterating Through Results

After query(), next() moves the GlideRecord pointer to the next record in the result set, making its fields accessible. hasNext() checks if there are more records.

var inc = new GlideRecord('incident');
inc.query();
// hasNext() is often implied by the while(inc.next()) loop condition
gs.print(inc.hasNext()); // Will return true if any records were found.

Result: Prints a boolean (true/false) indicating if there's at least one record.

get(sys_id) or get(field, value): Fetching a Single Record

Used to retrieve a specific record, typically by its sys_id or another unique field.

var inc = new GlideRecord('incident');
inc.get('number','INC0009005'); // Get by incident number
gs.print(inc.sys_id);

Result: Prints the sys_id of incident INC0009005.

var inc = new GlideRecord('incident');
if (inc.get('c4a6c42987a03010b985c186d643d4d4')) { // Get by sys_id (always returns true/false)
    gs.print(inc.number);
} else {
    gs.print("Record not found!");
}

Result: Prints the incident number related to the sys_id or "Record not found!".

Interview Relevance: Distinguishing between query() and get() is a common interview question. get() is for a single, known record; query() is for searching and returning multiple results.

getRowCount(): Counting Your Blessings

Returns the number of records in the GlideRecord result set.

var grUser = new GlideRecord('sys_user');
grUser.addQuery('active', true);
grUser.query();
gs.print('Active users are: ' + grUser.getRowCount());

Result: Prints the count of active users.

orderBy(field) and orderByDesc(field): Sorting Your Results

Sorts the query results in ascending or descending order by a specified field.

var inc = new GlideRecord('incident');
inc.addQuery('priority',1);
inc.orderByDesc('short_description'); // Sort by short description, descending
inc.query();
while(inc.next()){
    gs.print(inc.number + ' ' + inc.short_description);
}

Result: Prints priority 1 incidents, sorted by short description from Z to A.

setLimit(number): Limiting Your Output

Restricts the number of records returned by the query, useful for performance or previewing.

var inc = new GlideRecord('incident');
inc.addActiveQuery();
inc.setLimit(5); // Only retrieve the first 5 active incidents
inc.query();
while(inc.next()){
    gs.print(inc.number);
}

Result: Prints the first 5 active incident numbers.

chooseWindow(start, end): Paging Through Records

Selects a subset of records from the query results, starting from 'start' (inclusive) and ending before 'end' (exclusive).

var inc = new GlideRecord('incident');
inc.addQuery('priority',1);
inc.chooseWindow(3,7); // Get records from index 3 up to (but not including) 7 (i.e., records at index 3, 4, 5, 6)
inc.query();
while(inc.next()){
    gs.print(inc.number);
}

Result: Prints 4 incident numbers (the 4th, 5th, 6th, and 7th records in the priority 1 result set).

addJoinQuery(joinTable, primaryField, joinField): Connecting Related Tables

Allows you to perform queries that involve two related tables, similar to a SQL JOIN. This method returns records from the primary table that have a match in the joined table.

var prob = new GlideRecord('problem');
// Find problems where the 'opened_by' user is also the 'caller_id' of an incident
prob.addJoinQuery('incident', 'opened_by', 'caller_id');
prob.query();
while(prob.next()){
    gs.print(prob.number + ' | ' + prob.short_description);
}

Result: Displays problem records that have an associated incident where the opener of the problem is also the caller of an incident.

Troubleshooting: Join queries can be complex. Ensure your join fields are correctly specified and actually link the tables. For more complex joins or when you need data from both tables, consider using Script Includes with multiple GlideRecord queries or database views.

Creating, Updating, and Deleting Data (The "CUD" in CRUD)

These methods are for modifying the database.

initialize() and insert(): Creating New Records

initialize() prepares a new, empty GlideRecord object. You then set field values and call insert() to save the new record to the database.

var inc = new GlideRecord('incident');
inc.initialize(); // Get a blank incident form
inc.category = 'network'; // Set field values directly
inc.short_description = 'Firewall Issue Detected';
inc.priority = 1;
var newSysId = inc.insert(); // Insert the new record and get its sys_id
gs.print('New Incident: ' + inc.number + ' (Sys ID: ' + newSysId + ')');

Result: Creates a new incident, sets its category, description, and priority, then prints the new incident number and sys_id.

Interview Relevance: Understanding how to create records programmatically is essential for automation and integrations.

setValue(fieldName, value) and getElement(fieldName): Controlled Field Interaction

setValue() is another way to set field values, often preferred when the field name might be dynamic or for consistency. getElement() returns a GlideElement object for a specific field, giving you access to its properties and methods.

var inc = new GlideRecord('incident');
inc.initialize();
inc.setValue('category','network'); // Set category using setValue
inc.setValue('short_description','Critical VPN Issue');
var newSysId = inc.insert();
gs.print('Category: ' + inc.category + ', Issue: ' + inc.getElement('short_description').getDisplayValue());

Result: Creates a new incident, sets values, then prints them. getElement('short_description') here demonstrates getting the GlideElement, though inc.short_description works too.

update() and updateMultiple(): Modifying Existing Records

update() saves changes to the current GlideRecord object. updateMultiple() saves changes to all records that match the current query conditions.

var inc = new GlideRecord('incident');
if (inc.get('number','INC0000057')) { // Find the specific incident
    inc.setValue('state', 2); // Set state to 'In Progress'
    inc.update(); // Save changes to THIS record
    gs.print(inc.number + ' updated to state: ' + inc.state.getDisplayValue());
} else {
    gs.print('Incident INC0000057 not found.');
}

Result: Updates the state of incident INC0000057.

var inc = new GlideRecord('incident');
inc.addQuery('category', 'hardware'); // Query for all hardware incidents
inc.setValue('category', 'software'); // Change category to software
inc.updateMultiple(); // Apply changes to ALL matching records
gs.print('All hardware incidents changed to software category.');

Result: All incidents with category 'hardware' are updated to 'software'.

Warning! updateMultiple() is very powerful. Always be absolutely sure of your addQuery() conditions before using it, especially in production, to avoid unintended mass updates.

deleteRecord() and deleteMultiple(): Removing Records

deleteRecord() deletes the current GlideRecord. deleteMultiple() deletes all records that satisfy the query condition.

var inc = new GlideRecord('incident');
if (inc.get('number','INC0010013')) { // Find the specific record to delete
    inc.deleteRecord();
    gs.print('Incident INC0010013 deleted.');
} else {
    gs.print('Incident INC0010013 not found for deletion.');
}

Result: Deletes the incident INC0010013.

var inc = new GlideRecord('incident');
inc.addQuery('priority', 4); // Find all priority 4 incidents
inc.query();
var deletedCount = inc.getRowCount(); // Get count before deleting
inc.deleteMultiple();
gs.print(deletedCount + ' priority 4 incidents deleted.');

Result: Deletes all incidents with priority 4.

Extreme Warning! Use these methods with extreme caution. Deleting records is often irreversible. Consider using active=false or a custom 'status' field instead of actual deletion for auditability and recovery purposes.

Utility and Information Methods

getValue(fieldName) and getDisplayValue(fieldName): Raw vs. Readable

getValue() returns the raw, stored value of a field (e.g., '1' for priority 1). getDisplayValue() returns the user-friendly, displayed value (e.g., 'Critical' for priority 1).

var inc = new GlideRecord('incident');
inc.addQuery('priority',1);
inc.query();
if (inc.next()){
    gs.print('Raw priority: ' + inc.getValue('priority'));
    gs.print('Display priority: ' + inc.getDisplayValue('priority'));
}

Result: Prints "Raw priority: 1" and "Display priority: Critical".

Troubleshooting: When dealing with reference fields or choice lists, always remember the difference. If you're setting a reference field, you typically need the sys_id (raw value), but for display, you'll want the getDisplayValue().

getTableName() and getRecordClassName(): What Table Am I On?

Returns the name of the table the GlideRecord object is currently associated with.

var gr = new GlideRecord('change_request');
gs.print('Table Name: ' + gr.getTableName());
gs.info('Record Class Name: ' + gr.getRecordClassName()); // Often the same as getTableName() for standard tables

Result: Prints 'Table Name: change_request' and 'Record Class Name: change_request'.

isValid() and isValidField(fieldName): Checking for Existence

isValid() checks if the GlideRecord object was successfully instantiated for a valid table. isValidField() checks if a specific field exists on that table.

var inc = new GlideRecord('incident');
gs.print('Is incident a valid table? ' + inc.isValid()); // True

var invalidGr = new GlideRecord('non_existent_table');
gs.print('Is non_existent_table a valid table? ' + invalidGr.isValid()); // False

gs.print('Does incident table have "category" field? ' + inc.isValidField('category')); // True
gs.print('Does incident table have "uday_custom_field" field? ' + inc.isValidField('uday_custom_field')); // False

Result: Prints boolean values based on table and field existence.

Troubleshooting: Use these methods to prevent runtime errors in your scripts, especially when dealing with dynamic table or field names.

isNewRecord() and newRecord(): New Record Status

isNewRecord() returns true if the current GlideRecord hasn't been inserted into the database yet. newRecord() is an alternative to initialize() that also assigns a unique ID immediately.

var inc = new GlideRecord('incident');
inc.newRecord(); // Prepares a new record, assigns a sys_id
gs.info('Is this a new record? ' + inc.isNewRecord()); // True
inc.short_description = 'My brand new incident';
inc.insert();
gs.info('Is this a new record after insert? ' + inc.isNewRecord()); // False

Result: Prints 'True' then 'False', showing the lifecycle of a new record.

getLink(includeDomain) and gs.getProperty('glide.servlet.uri'): Getting a Record's URL

Constructs a direct link to the record, useful for notifications or external integrations.

var inc = new GlideRecord('incident');
inc.addQuery('priority',1);
inc.setLimit(1); // Get just one
inc.query();
if(inc.next()){
    var baseURL = gs.getProperty('glide.servlet.uri'); // e.g., https://dev12345.service-now.com/
    var recordLink = inc.getLink(false); // e.g., /incident.do?sys_id=...
    gs.print('Record URL: ' + baseURL + recordLink);
}

Result: Prints a clickable URL to the incident record.

canCreate(), canRead(), canWrite(), canDelete(): ACL Checks

These methods check if the currently logged-in user (or the user running the script) has the necessary permissions (ACLs) to perform the respective operation on the current record or table.

var inc = new GlideRecord('incident');
gs.print('Can create incident? ' + inc.canCreate());
inc.query();
if (inc.next()) {
    gs.print('Can read this incident? ' + inc.canRead());
    gs.print('Can write to this incident? ' + inc.canWrite());
    gs.print('Can delete this incident? ' + inc.canDelete());
}

Result: Prints boolean values indicating the user's permissions. This is great for building dynamic UIs or validating actions.

autoSysFields(boolean) and setWorkflow(boolean): Controlling System Behavior

These are powerful methods for advanced scripting, particularly when importing data or performing bulk updates where you don't want standard system behavior.

• autoSysFields(false): Prevents system fields like sys_updated_by, sys_updated_on, sys_mod_count, etc., from being updated when you save a record.
• setWorkflow(false): Prevents Business Rules, Workflow engines, and Flow Designer flows from executing when the record is updated.

var inc = new GlideRecord('incident');
inc.addQuery('state', 1); // Find all 'New' incidents
inc.query();
while (inc.next()) {
    inc.autoSysFields(false); // Don't update system fields
    inc.setWorkflow(false); // Don't trigger business rules/workflows
    inc.setValue('state', 2); // Set state to 'In Progress'
    inc.update();
}
gs.print('Updated incidents without triggering system fields/workflows.');

Result: Updates incidents without changing audit fields or running associated business logic.

Warning: Use these with extreme care! Disabling system behavior can lead to auditability issues, unexpected data, or broken workflows if not done deliberately and correctly. Usually reserved for specific integration scenarios or data clean-up.

setAbortAction(true): Stopping the Show

Used in Business Rules (specifically `before` Business Rules) to stop the current database operation (insert, update, delete) from completing if a condition isn't met. It's crucial for server-side validation.

// Example in a 'before' Business Rule
// Scenario: Prevent saving if u_date1 is after u_date2
if ((!current.u_date1.nil()) && (!current.u_date2.nil())) {
    var start = current.u_date1.getGlideObject().getNumericValue(); // Get numeric value for comparison
    var end = current.u_date2.getGlideObject().getNumericValue();
    if (start > end) {
        gs.addInfoMessage('Start date must be before end date.');
        current.u_date1.setError('Start date must be before end date.'); // Highlight the field
        current.setAbortAction(true); // Stop the save operation
    }
}

Result: If the condition (start date after end date) is met, an info message is shown, the field is highlighted, and the record save is aborted.

Troubleshooting: If a record isn't saving and you've used setAbortAction(true), check the conditions leading to it. Also, ensure you provide clear messages to the user (gs.addInfoMessage() or current.field.setError()) so they understand why the action failed.

GlideForm (g_form): Your Tool for Client-Side UI Control

While GlideRecord handles server-side data, g_form is your primary interface for manipulating the form that users interact with directly in their browser. It's all about enhancing the user experience, guiding users, and enforcing client-side validation.

GlideForm Overview and Usage

The g_form object is a global client-side API, meaning it's available and runs within the user's browser whenever a form is loaded. You'll primarily use g_form methods within Client Scripts (and sometimes UI Policies, though UI Policies often provide a no-code alternative for simpler tasks). Its main goal is to change the default behavior and appearance of the current record's form view.

Common uses include:

• Setting/getting field values based on other field changes.
• Making fields mandatory or read-only conditionally.
• Hiding or showing fields/sections.
• Displaying informational or error messages to the user.
• Modifying choice list options dynamically.

GlideForm Methods: Sculpting the User Interface

Let's look at some key g_form methods. For these exercises, remember you typically run them in a Client Script, but for quick testing, you can use the JavaScript Executor (Ctrl+Shift+J or Cmd+Shift+J) in your browser developer tools while on a ServiceNow form.

getValue(fieldName) and setValue(fieldName, value): Field Interaction

The client-side counterparts to GlideRecord's getValue() and setValue().

// In browser's JavaScript Executor on an incident form:
alert(g_form.getValue('category')); // Get current category
g_form.setValue('category', 'hardware'); // Set category to hardware

Result: First, an alert with the current category. Then, the category field on the form changes to 'Hardware'.

setMandatory(fieldName, boolean), setReadOnly(fieldName, boolean), setDisplay(fieldName, boolean), setVisible(fieldName, boolean): Controlling Field State

These methods allow you to dynamically control the visibility, editability, and mandatory status of fields.

• setMandatory(field, true/false): Makes a field required or optional.
• setReadOnly(field, true/false): Makes a field editable or read-only.
• setDisplay(field, true/false): Completely removes a field from the form layout (taking up no space).
• setVisible(field, true/false): Hides a field but preserves its space in the layout.

// In Client Script or JS Executor:
g_form.setMandatory('short_description', true); // Make short_description required
g_form.setReadOnly('impact', true);           // Make impact read-only
g_form.setDisplay('business_service', false);  // Hide Business Service field
g_form.setVisible('subcategory', false);       // Hide Subcategory, but keep its space

Result: The fields change their state on the form immediately.

Best Practice Note: For simple conditional mandatory, read-only, or visibility changes, UI Policies are generally preferred over Client Scripts as they are declarative (no code), easier to maintain, and perform slightly better. Use g_form in Client Scripts when you need more complex logic, AJAX calls, or interactions not possible with UI Policies.

addInfoMessage(message), addErrorMessage(message), clearMessages(), showErrorBox(fieldName, message): Communicating with the User

Display messages at the top of the form or next to a specific field.

// In Client Script or JS Executor:
g_form.addInfoMessage('This is an important info message!');
g_form.addErrorMessage('Something went wrong. Please check your input.');
// g_form.clearMessages(); // Clears all messages
g_form.showErrorBox('short_description', 'This field cannot be empty!'); // Error next to field

Result: Messages appear on the form. The showErrorBox highlights the specified field.

addOption(fieldName, choiceValue, choiceLabel, index) and removeOption(fieldName, choiceValue): Dynamic Choice Lists

Modify the options available in a choice list field (e.g., a dropdown).

// In a Client Script (e.g., onChange of 'category' field)
// Assuming 'subcategory' is the target field
g_form.clearOptions('subcategory'); // Clear existing options first
g_form.addOption('subcategory', 'network_issue', 'Network Issue', 0); // Add new option
g_form.addOption('subcategory', 'vpn_problem', 'VPN Problem', 1);

Result: The 'Subcategory' dropdown now only shows 'Network Issue' and 'VPN Problem'.

Troubleshooting: Ensure the fieldName is correct. For choice lists, remember to clear existing options before adding new ones if you want to replace them entirely. Dynamic choice lists are often driven by an onChange Client Script on a parent field.

getUniqueValue() and getTableName(): Form Context

getUniqueValue() returns the sys_id of the current record displayed on the form. getTableName() returns the name of the table the form is for.

alert('Current Record Sys ID: ' + g_form.getUniqueValue());
alert('Current Table Name: ' + g_form.getTableName());

Result: Alerts with the sys_id and table name of the current form record.

isNewRecord(): Check if it's a New Form

Determines if the current form is for a new record (not yet saved to the database) or an existing one.

alert('Is this a new record? ' + g_form.isNewRecord());

Result: Alerts 'true' if it's a new form (e.g., 'new incident' form), 'false' if it's an existing record.

save() and submit(): Programmatic Form Actions

save() saves the form without closing it. submit() saves the form and closes it, returning to the previous page (e.g., a list view).

// g_form.save();
// g_form.submit();

Warning: Use these with caution in Client Scripts, as they can interfere with user experience if not triggered appropriately (e.g., after user confirmation).

Troubleshooting Common API Integration Issues

Even with the best intentions, things can go wrong. Here are some common pitfalls and how to troubleshoot them:

• "Script Error" / Uncaught Reference Error: Check for typos in variable names, method names (e.g., query() vs. Query()), or missing semicolons. Use your browser's developer console (F12) for client-side errors, and the ServiceNow System Logs for server-side errors.
• No Records Found / Incorrect Data:
  • Server-Side (GlideRecord): Double-check your addQuery() conditions. Are the field names correct? Are the values case-sensitive if they should be? Test your exact query in a list view by copying it to addEncodedQuery() to see if it returns records.
  • Client-Side (g_form): Is the field name correct? Does the field exist and is it visible on the form?
• Performance Issues:
  • Server-Side: Avoid querying large tables inside loops (N+1 query problem). Use setLimit() when you only need a few records. Ensure your queries are indexed. Check logs for slow queries.
  • Client-Side: Too many complex Client Scripts can slow down form load. Optimize your code, combine scripts where possible, and prefer UI Policies for simple actions.
• ACL Violations (Server-Side): If your script isn't able to create, update, or delete records, or access certain fields, it's likely an ACL issue. The user running the script (or the system user if it's a background script/scheduled job) might not have the necessary roles. Check the `sys_security_acl` table.
• Conflicting Scripts/Policies (Client-Side): If a field isn't behaving as expected (e.g., staying mandatory despite your script), check for other Client Scripts or UI Policies that might be overriding your logic. Order of execution matters!
• Debugging:
  • Server-Side: Use gs.print() or gs.info() statements throughout your code to trace execution and variable values. Use the "Script - Background" module or debugger in Script Includes.
  • Client-Side: Use console.log() and the browser's developer tools (F12) to inspect variables, step through code, and identify errors.

Interview Relevance: What You Need to Know

API integration, especially with GlideRecord and GlideForm, is a cornerstone of ServiceNow development. You will absolutely be asked about these topics in interviews. Be prepared to:

• Explain the difference between client-side and server-side scripting: What are their contexts, advantages, and limitations?
• Describe GlideRecord in detail: What is it? What does it do? How do you perform CRUD operations?
• Give examples of common GlideRecord methods: Be ready to write simple code snippets for query(), addQuery(), get(), insert(), update(), and deleteRecord().
• Discuss best practices for GlideRecord: Why test in non-prod? When to use setLimit(), setWorkflow(false), autoSysFields(false)?
• Explain g_form: Its purpose, where it runs, and common methods like setValue(), setMandatory(), addInfoMessage().
• Compare and contrast Client Scripts vs. UI Policies: When to use one over the other for UI modifications.
• Talk about GlideAjax: How do client scripts get server-side data or logic without a page refresh?
• Troubleshooting skills: How would you debug a script that isn't working as expected?

Conclusion: Your Journey to ServiceNow Mastery

Congratulations! You've just taken a significant step in understanding the critical role of API integration in ServiceNow. From the server-side might of GlideRecord to the client-side finesse of GlideForm, these APIs empower you to customize, automate, and integrate ServiceNow in ways that truly unlock its potential.

Remember, theory is just the beginning. The real learning happens when you roll up your sleeves and start scripting. Use your personal developer instance, experiment with these methods, and don't be afraid to make mistakes – that's how we learn. The more you practice, the more intuitive these powerful tools will become. Happy scripting!