If a string field contains an emoji smiley icon (for example, from an email sent from a windows phone), all content after the smiley icon is missing. The logs show the following exception:

java.sql.SQLException: Incorrect string value: '\xF0\x9F\x98\x83\xF0\x9F...' for column 'body' at row 1

The problem is the field compatibility with Unicode characters with four or more bytes (for example, smiley face).

Steps to Reproduce


  1. Send an email to an instance containing the following text in the body:

    Hello , happy face emoji     😄      <--- then, more information

    Sending email with emoji

    Note that you only receive "Hello , happy face emoji." All data after the emoji is lost on the sys_email record.

    Data lost by emoji


This issue is fixed in Kingston.

On earlier releases, create a business rule to strip the emoji characters from the subject, body_text, and body_html fields of the email upon insert. You may also need to have this business rule run on 'update' if your implementation allows further updating of the content of a sys_email record and an emoji could be introduced.

Since Geneva you can use the field type 'String (Full-UTF8)', which is capable of handling the 4 byte emoji's character.  One might change the body_html, body_text, and subject to prevent truncation, however it is not an adequate e2e email flow workaround because of other platform issues with emoji characters:

    • PRB832997 - Copy from String (Full-UTF8) to String causes data truncation
      Example: copying email subject - with 'String (Full UTF-8)' field type - containing an emoji to incident description (String type) would manifest truncation.
    • PRB833032 - Unable to create Journal Input that supports UTF-8
      Example: copying email body with 'String (Full UTF-8)' field type,  - containing an emoji to worknotes would manifest truncation.


Here is an example of changing the body field on sys_email to String (Full UTF-8):

Set your string as String (Fully UTF-8)


More information here:
* https://docs.servicenow.com/bundle/istanbul-servicenow-platform/page/administer/reference-pages/reference/r_FieldTypes.html

Please note this will avoid the truncated data on the sys_email table. If you later need to use the data with emojis on it, please remove the emoji characters if the target fields are not fully UTF-8 compatible (e.g. normal String field).

Here are some example functions to remove the emoji characters:


  1. Create a new Business Rule
  2. Table sys_email
  3. When to run: before insert
  4. Enable the Advanced checkbox
  5. Empty the Script field and insert the following code:
function remove4ByteUTF8Unicodecharacters(a) { return a ? a.replace(/^[\0\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]/g, "") : "" };


  1. Create a new Business Rule
  2. Select table sys_email
  3. Default application should be Global
  4. When to run: before insert/update
  5. Add filter conditions:
    Type: send-failed, send-ready
    Headers contains X-ServiceNow-Source:EmailInbound
  6. Enable the Advanced checkbox
  7. Empty the Script field and insert the custom script:
(function executeRule(current, previous /*null when async*/) { 
// emoticons truncate emails, so remove them prior to insert 
gs.log ("Cleaning up Email Test:"); 
current.body_text = current.body_text.toString().replace(/^[\0\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]/g, ''); 
current.body = current.body_text.toString().replace(/^[\0\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]/g, ''); 
})(current, previous);

Related Problem: PRB627055

Seen In

Dublin Patch 1
Eureka Patch 10
Eureka Patch 11 Hot Fix 2
Eureka Patch 8
Eureka Patch 9 Hot Fix 1
Fuji Patch 12 Hot Fix 1
Fuji Patch 13 Hot Fix 1
Fuji Patch 5
Fuji Patch 7 Hot Fix 5
Fuji Patch 8
Geneva Patch 7
Helsinki Patch 2

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2018-03-20 03:59:54