You have built an email script that gets information for the user that created a new record, and includes the user Name it in the subject of an email notification fired on record creation.

Here is the sequence of steps used in the email script:


1. Define a GlideRecord query object on sys_user table.

2. Set as query condition user_name = current.sys_updated_by.

3. Execute the query and get the user name from the glide record.

4. Build the notification subject  using email.setSubject( ) and including the retrieved user name.


However, the notification not always includes the user name in the subject, sometimes just set an (empty) subject.



Release or Environment

Any supported release.


It is incorrect to assume that no other user or process will update the same record before the notification is sent, which may not be true.

To analyze better this scenario, it is important to understand what happen between the creation of a new record and generation of the correspondent notification.


Let's say that a new incident record has been just created by a user 'A', and then the "sys_updated_by" field will contain the "sys_id" for user 'A'. 

The following events will happen when the notification due to the record creation is fired:


a) A new event "notification_engine.process" or a "custom event" will be inserted in the "sysevent" table.

b) The notification event will be waiting in the "sysevent" queue to be processed by the event processor job that runs every 10 seconds.

c) Once the "notification_engine.process" or a "custom event" is processed, a "sys_email" record is created with the notification content. This steps includes the execution of the email script.

d) Finally the SMTP Sender job will process the entry in "sys_email"  and will send the email.


Notice that several seconds could pass since the creation of the notification event and the final build of the email notification. During this time if other user 'B' or process updates the incident record then you may not see what you expect in the notification subject. Chances are that you will see in the email subject user 'B' or no user if a business rule updated the record. Business rules run under 'system' user which is internal to the platform and does not exist in sys_user table.



For the use case above a much better field choice is current.sys_created_by as this field will not change due to record updates. 

While creating new notifications, think about all possible things that may happen to the record during the notification creation.

  • Always consider that the state of the record may change from the moment that is created to the moment that the notification is built.
  • Assignment groups, updated by, category, etc are fields commonly used in notifications. Is there anything that may change those values during the next 10 or 15 seconds?
  • Think about what business rules may fire and update the record as soon as is created or updated.
  • Analyze if the logic used in your notification and notification scripts is robust enough to consider the possibility of a record transition while the notification is processed and sent. 

Article Information

Last Updated:2020-06-14 04:43:33