Diacritical Characters Lost During Import - UTF-8 Encoding Configuration Required - Support and Troubleshooting

Diacritical Characters Lost During Import - UTF-8 Encoding Configuration Required Issue .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: ; } } Diacritical characters (accented letters such as Polish "Ł", German "ü", French "é", etc.) are being lost, corrupted, or replaced with incorrect characters during user import into ServiceNow. User names containing special characters are imported with characters missing.

Symptoms .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 importing user data into ServiceNow sys_user table:

User names containing diacritical characters are imported with characters missing Example: "Łtest" imports as "test" (Ł is dropped) Example: "hüller" imports as "huller" (ü is replaced or dropped) Import logs show correct diacritical characters, but sys_user table displays corrupted names Multiple users affected across the import batch Special characters are either completely removed or replaced with unrelated symbols Issue occurs consistently with every import attempt Release .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: ; } } This issue affects all ServiceNow releases when importing data with diacritical characters from external sources via API calls or file-based imports (CSV, Excel, etc.).

Cause .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: ; } } The root cause is improper character encoding at the source system level. When user data is exported or transmitted from the source system without proper UTF-8 encoding specification, ServiceNow's import processor cannot correctly interpret diacritical characters.

Specific encoding problems:

Source system exports data with UTF-16, ANSI, WINDOWS-1252, or unknown/mixed charset formats Data file contains BOM (Byte Order Mark) characters at the beginning (ÿþ or similar) Source API does not specify UTF-8 encoding in the request headers File encoding metadata is missing or incorrectly set When ServiceNow receives this improperly encoded data, the import processor misinterprets diacritical characters as corrupted bytes, resulting in character loss or replacement.

This is NOT a ServiceNow configuration issue. The problem originates from the source system sending data without proper encoding.

Resolution .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: ; } } Step 1: Identify Your Data Source Type Determine whether your user data is being sent via:

File-based import (CSV, Excel, text file) API call integration SFTP/FTP transfer Direct database connection Document the current transmission method used by your source system.

Step 2: Verify Source Data Encoding Download a sample of user data from your source system Open the sample in a text editor that displays encoding (Notepad++, VS Code, Sublime Text) Check the file encoding setting — it should display UTF-8 Verify diacritical characters (Ł, ü, é, etc.) are visible and correct in the sample Check the file start — there should be NO BOM characters (ÿþ or similar) If encoding is NOT UTF-8:

In the text editor, convert to UTF-8 (Encoding menu > Convert to UTF-8) Save the file Re-verify that special characters remain intact Step 3: Coordinate UTF-8 Requirement with Source System Contact your source system owner/vendor and provide these requirements:

Mandatory Requirements:

All data must be exported/transmitted with UTF-8 character encoding No BOM (Byte Order Mark) characters should be present in the data Diacritical characters must be preserved in the output without modification If API-based: UTF-8 encoding must be specified in request headers Request confirmation that these requirements are met and the source system has been configured to export with UTF-8 encoding.

Step 4: If File-Based Import — Update File Encoding For CSV or Excel files:

Open the file in your system (Excel, text editor, etc.) Go to File > Save As Change file format to CSV UTF-8 (or equivalent in your editor) Save with the new encoding Verify that diacritical characters are still present and correct For text files:

Open in Notepad++ Go to Encoding menu Select Convert to UTF-8 Save the file Step 5: If API-Based Import — Verify UTF-8 Headers If data is sent via API:

Verify the API request includes UTF-8 encoding header: Content-Type: application/json; charset=utf-8 Confirm the source system API is configured to send UTF-8 encoded data Test an API call with sample data containing diacritical characters Verify characters are preserved in the API response Step 6: Clean Up Affected Records Query table in question for affected records (those with missing or corrupted diacritical characters) Either: Option A: Delete the affected records and re-import with corrected UTF-8 data Option B: Manually correct the records in ServiceNow if re-import is not possible Document which records were affected for reference Step 7: Re-Import User Data Once your source system confirms UTF-8 encoding is configured:

Prepare the corrected data export with UTF-8 encoding Upload the file or initiate the API call from the corrected source system Run the import/data load in ServiceNow Verify in table that diacritical characters are now saved correctly: "Łtest" should display as "Łtest" (not "test") Step 8: Prevent Future Issues Document the UTF-8 encoding requirement with your source system vendor Request that all future user exports use UTF-8 encoding by default Set up periodic validation checks on imported data to catch encoding issues early Add UTF-8 encoding specification to any integration documentation Expected Outcome Once the source system is configured to send data with UTF-8 encoding and no BOM characters, user names containing diacritical characters will be imported and stored correctly in ServiceNow sys_user table without any character loss or corruption.