What I particularly like about the ServiceNow platform is that even having dealt with it for as long as 15 years, you keep learning new things all the time. As I was working on my post about reminders earlier this week, I noticed that each time I opened a new reminder form, three fields – Remind me, Before and Using – got prefilled with the values I had used for the previous reminder. In the absence of any client scripts and UI policies for Reminder [reminder] table, my first thought was that this was some odd behavior of my web browser. However, switching to a different one made no difference. Two out of those three fields turned out to have a default value set in the Dictionary. So what could be the reason for it to fail to be applied?

At that point, my gut feeling directed me towards user preferences. And indeed three strange user preference records of the format FM.<table_name>.<field_name>, which I had never seen before, were there in the User Preference [sys_user_preference] table. There was no doubt that they were involved in the magic, but it was still unclear how and why they got created and applied.

After some more research, I finally figured it out. The dictionary attribute named user_preference was the missing piece:

Although it is listed in the product documentation among other available dictionary attributes, I never paid attention to it because – guess what? – the two fields from the Reminder table are, in fact, the only ones in the entire system that have that attribute. Well, to be perfectly honest, there is also the collection record corresponding to On-Call User Contact Preference [on_call_user_contact_preference] table, but technically it is not a field and, moreover, it doesn’t seem to have the same effect. Not sure what the purpose of applying the attribute to that record is. Maybe you can figure it out and let me know in the comments.

Additionally, it is worth mentioning that – despite being applicable to any field, according to the documentation – the attribute has an important limitation, of which the documentation makes no mention. It doesn’t work properly for fields derived from a parent class. On the Incident form, for example, it works well with the close_code field, but not with the contact_type field.

Do you know about other dictionary attributes that are rarely used? Let me and other readers know in the comments.