Difference on number field on sys_watermark table default value

gazalagrawa
Tera Contributor

I found there is a difference in default value of number field of sys_watermark table. Both are at OOB version, when I changed it, it stopped evening receiving email on the instance. What does this difference mean? What configuration do I need to do to make it working such that email having same watermark in sub/body should be considered as Reply not new.

Working instance:

Screenshot 2026-05-14 215416.png

 




Instance with issue

Screenshot 2026-05-14 215729.png

 

 

6 REPLIES 6

Naveen20
ServiceNow Employee
Working instance wraps the watermark in GlideEmailWatermark().optionallyRandomize(...), which appends a random 20-character suffix (e.g., MSG0010001_aB3xK9...). The other instance generates only the padded number (MSG0010001) with no randomization.

 

Why replies break: When glide.email.watermark.generate_random = true AND glide.email.watermark.parse_restrictive = true (OOB defaults on current releases), inbound email parsing only accepts the randomized format. Non-randomized watermarks are ignored, so replies are treated as new emails. Reference: KB0657249.

 

2 Fixes :

 

1. Recommended: Restore the OOB default value on the sys_watermark.number dictionary entry:

 

javascript:new GlideEmailWatermark().optionallyRandomize(new NumberManager('sys_watermark').getNextObjNumberPadded());

 

2. Or set glide.email.watermark.parse_restrictive = false in sys_properties to accept both formats (useful during transition while old non-random watermarks are still in circulation).

 

After fixing, send a fresh notification and reply to that — old emails sent with the broken default will never match.

I will try option 2

 

But I tried option 1, in this case email itself did not come in when I reverted to random padding

Hey I tried both the approaches, in both cases if there is a new email (with re/fw) but have watermark, it is even not coming in the logs.

Naveen20
ServiceNow Employee

Can you check 

sys_email table — filter Type = Received for the last hour. If the email is there but state is Error or Ignored, the issue is processing, not delivery. If it's not there at all, the email never reached the instance.