The string field in the import set staging table is not saving the string values as entered in the Excel sheet; instead, it stores them as an integer "0."Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } When loading data into a staging table through a file-type data source, a string field consistently receives the value "0" instead of the value provided in the source file. This happens even when the field is defined as a String type in the ServiceNow platform dictionary and the source data contains valid string values. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All currently supported releases. Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } A mismatch between the ServiceNow UI field type and backend data type caused import values to be incorrectly set as '0'.The platform dictionary described the field as a string, but the database had it as an integer. During import, string values were silently converted to integers, with non-numeric inputs turning into '0' unnoticed.This mismatch can occur when a staging table name exceeds 30 characters. In such cases, the persistence layer creates a storage alias with an abbreviated physical table name.If the logical (dictionary) table and its physical alias become out of sync—such as after deleting and recreating a field or following a database migration—the column type in the physical alias table may not match the dictionary definition. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } **Note:** The steps below require backend database access. If you do not have this access, raise a support case with ServiceNow Technical Support and reference this article. 1. Confirm the field type mismatch by comparing the platform dictionary entry for the affected field against the database column definition. The dictionary should show 'string'; if the physical table shows 'integer', the mismatch is confirmed. 2. Confirm whether the staging table name exceeds 32 characters. If it does, look up the physical (aliased) table name by navigating to **System Definition > Storage Table Aliases** ('sys_storage_table_alias.list') and filtering by the logical table name. 3. Alter the affected column's data type in the physical table from 'integer' to 'sncvarchar(100)' (or the appropriate string length for your field). This change must be tested on a sub-production instance before being applied to production. 4. After the column type correction is applied, flush the cache for both the logical table and the physical alias table by running the script below as a background script. Flushing only one is not sufficient — both must be refreshed. GlideTableManager.invalidateTable("TABLENAME"); 5. Verify the fix by navigating to the staging table in your ServiceNow instance and manually entering a string value in the affected field. Confirm the value saves correctly. 6. Re-run the data source import and confirm that the field now receives the correct string values from the source file. ***Alternative options if a backend fix cannot be performed immediately:*** - Delete the affected column from the staging table dictionary and allow the import to regenerate it. This will only resolve the issue if the physical alias table is in a clean state; if the alias is also corrupted, the column will regenerate with the same incorrect type.- Create a new staging table and point the data source to it. The new table will generate columns with the correct types.- Rename the field in the staging table dictionary and update all dependent transform maps, scripts, and integrations accordingly.