Data type mismatch: expected integer, got string

A script directly assigns a string value to a GlideRecord field that expects an integer, such as setting gr.number_field = 'text' instead of gr.number_field = 123. (high likelihood)

User input from forms or REST API calls contains non-numeric characters that are passed to integer fields without proper validation or conversion. (high likelihood)

Transform Maps are configured to map string source values directly to integer destination fields without field mapping scripts or coercion rules. (medium likelihood)

JavaScript variables contain unexpected string values due to incorrect data retrieval or manipulation before being assigned to integer GlideRecord fields. (medium likelihood)

Custom UI actions or client scripts pass form field values as strings to server-side functions that expect numeric parameters for database operations. (low likelihood)

Step 1: Check the System Log at System Diagnostics > Log Files > Node Log File to identify the exact script file and line number where the error occurs.

Step 2: Navigate to the problematic script (Business Rule, Script Include, or Transform Map) and locate the line that assigns values to integer fields.

Step 3: Examine the source of the data being assigned and verify what type of value it contains using typeof operator or gs.log() statements for debugging.

Step 4: Convert string values to integers using parseInt(), parseFloat(), or Number() functions before assignment, ensuring proper validation for non-numeric input.

Step 5: Add input validation to check if the value is numeric using isNaN() function and handle cases where conversion fails with appropriate error handling.

Step 6: For Transform Maps, configure Field Maps with appropriate scripting to handle data type conversion or use the Advanced tab for complex transformations.

Step 7: Test the fix by reproducing the original conditions that triggered the error and verify that integer fields now receive properly formatted numeric values.

Step 8: Monitor the System Log for 24-48 hours after deployment to ensure the error no longer appears and no new related issues have emerged.