Escape Special Characters in UI Messages

UI Messages look like plain text until one of them passes through a JavaScript or Jelly-rendered path and suddenly stops at the first apostrophe.

That failure usually shows up as a message that looks truncated, a broken client-side string, or a banner that renders only the first part of the sentence.

The safe habit is simple: if the message will be interpreted in a JavaScript context, escape special characters before it gets there.

1. Why a single quote breaks the message

In JavaScript, a single quote can terminate a single-quoted string.

So this:

var msg = 'User can't submit this request';

is not a valid string. The apostrophe in can't closes the text early.

ServiceNow has the same concern anywhere the message ends up being emitted into JavaScript or a Jelly expression with JavaScript escaping. That is why an apparently harmless UI Message can behave badly even though the text itself looks normal in the record.

2. The common UI Message mistake

Suppose you create a UI Message for a client-side validation:

• key: request_locked_message
• text: This request can't be updated after approval starts.

If that message is later inserted into a JavaScript-rendered context without proper escaping, the output can be cut at can or produce a script error, depending on where it is used.

The safer value is:

• text: This request can\'t be updated after approval starts.

What the user sees is still:

• This request can't be updated after approval starts.

The backslash is for the interpreter, not the end user.

3. JavaScript escaping and HTML escaping are different problems

These two contexts are easy to mix up.

If the message is going into JavaScript, escape JavaScript characters:

• ' becomes \'
• " becomes \"
• newlines become \n

If the message is being written into HTML, escape HTML characters:

• & becomes &
• < becomes <
• > becomes >

That distinction matters. Developers sometimes try to fix an apostrophe with an HTML entity or try to fix HTML output with JavaScript escaping. That only moves the bug around.

4. Where this usually shows up

This issue is most common when UI Messages are consumed by:

• client scripts
• UI scripts
• UI pages and Jelly
• portal or widget code that emits the message into JavaScript first

A simple pattern is:

g_form.addErrorMessage(getMessage("request_locked_message"));

That call looks harmless, but the message still has to survive the path from the message table to the client-side renderer.

If you are working in Jelly, be explicit about context:

${JS:gs.getMessage("request_locked_message")}

The right escaping depends on where the message is inserted, not only on where the message originated.

5. Escaping is part of localization quality

UI Messages are often created because the text will be translated.

That means the escaping rule does not stop with the base language. If the English message uses \', but the translated French or Spanish value reintroduces an unescaped apostrophe in a JavaScript-rendered path, the translated version can break while English keeps working.

So when you localize UI Messages:

• review translated values for quotes and line breaks
• test them in the real UI, not only in the table
• keep placeholders and escape characters intact

Localization bugs are often really escaping bugs.

6. A practical rule of thumb

When a UI Message contains punctuation, ask one question first:

Where will this message be rendered?

If the answer is JavaScript or Jelly-to-JavaScript, escape it like JavaScript. If the answer is HTML, escape it like HTML. If you are not sure, test the exact rendering path instead of assuming plain text rules apply.

A safe default for apostrophes in JavaScript-facing messages is:

You can\'t submit this form yet.

7. Keep the message readable anyway

Escaping is an implementation detail. The user should still get a short, clear sentence.

Good:

• You can\'t close the task while approvals are pending.

Less good:

• Close action failed because current approval state prohibits record update.

The point of UI Messages is clarity for the user, not cleverness in the script.

Final thought

UI Messages are easy to underestimate because they look like content, not code.

But the moment they are rendered through JavaScript or Jelly, special characters matter. If a message contains an apostrophe, treat it as a parsing concern, not just punctuation.

A small escape like \' is often the difference between a clean message and a confusing broken one.