After my first post "Do not run into that weird Flow Designer bug" once again, I was confronted with a strange flow problem that caused me some headaches and time wastage in my current project. If your ServiceNow instance is in the same time zone as all of your users, you will probably not run into it. But in today's globalized world, this can probably hardly be ruled out.
Problem description
One of our Flows has a timer triggered which should start each day at 05:05 am:
On DEV and TEST the flow has started correctly at this time. And also on PROD it ran well for a while. But then from one day to the other the flow always started one hour later, that is at 06:05 am. We checked everything, but in all instances the configurations were identical. As all of our analyses did not lead to any result, we left this behavior as it was. Recently I rebuilt this flow and on DEV and TEST it started correctly at 05:05 am, but PROD it started from the beginning at 06:05 am and this time I wanted to get to the bottom of it.
Problem Analysis
To understand what's going wrong here, we need to take a look under the hood. Even though a flow can become quite complex and consists of many different artifacts, it is always transported as a whole via the sys_update_xml table. To find the corresponding record, just copy the Sys ID of the flow from the address field of the browser and search for sys_hub_flow_[SYS ID] in the "Name" field of the sys_update_xml table:
In the "Payload" field of this record, a browser search for "Trigger" reveals two tables that have something to do with the time trigger:
The record at table sys_flow_timer_trigger belongs to the Flow and contains the timer configuration:
But configurations for repeated actions are done in other tables. Therefore, the related record at table sys_flow_trigger_auto_script (child of sysauto_script) is created automatically by ServiceNow.
At first glance, this record does not look suspicious. However, experienced ServiceNow users know that these records of the table sysauto_script (and all of its children) also represent only the configurations for the actual jobs, which can be found in the sys_trigger table.
It is not difficult to find the corresponding record in the sys_trigger table, because it has the same name as the record in the table sys_flow_trigger_auto_script.
And with the opening of this record, the reason for the job starting 1 hour later becomes visible for the first time. But why does ServiceNow add an hour to the configured start time?
After researching the Internet, I came across the following support article: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0750527. Even though the scenario described in this article is somewhat different from our setting, one passage of text made me wonder:
"This is expected behavior, only occurring when users are set in a timezone with daylight savings, since "Run Time" is a GlideTime field, so daylight savings unaware.' Run Time' can differ by the actual time if the job is created in daylight saving timezone (DST) and viewed in non-DST."
For this reason, I finally took the decisive step and clicked on the question mark icon (thanks Arnoud Kooi for the amazing SNUtils browser extension) in the form view of the sys_trigger record. Here I could see that it was not created by me, but by one of the Indian Ops team members who deployed the release to the PROD environment. While on the DEV the sys_trigger record was created in my name by ServiceNow, on the PROD ServiceNow created the record in the name of the user who deployed the release and the flow it contained.
And in India there are no time changes twice a year like here in Europe. This means that in one half of the year and compared to India daylight saving time does not matter - but in the other half it does. This was also the reason why at the beginning of the year the flow was started as configured, but then all of a sudden an hour later. The tipping point was here the 26th of March where our clocks were set forward one hour.
Problem Fixing
Unfortunately, there is no way to eliminate the problem at its root, because ServiceNow developers forgot to implement a time zone picker for the Flow Designer's timer trigger. This is quite remarkable in my opinion, because I can't understand why nobody has missed this option yet.
But what you can do is modifying the automatically created sys_flow_trigger_auto_script record and there you can specify the same timezone as the system's time zone to make sure that ServiceNow does not look up the time zone of the user who created the sys_trigger record.
And if the Flow trigger is not changed anymore also that record remains untouched.
1 Comment
