- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-16-2022 11:50 PM
Hi experts,
I've run into a weird problem. I've a notification setup as follows:
When to run:
Who will receive:
What will it contain:
Then I use a background script to update the record's substatus (which is happening as I check it in the form view)
But when I open the sys_email table and try to find any record of this email, I fail to see any rows. What could be causing it to fail?
Additionally, even the gs.info statement in the "Advanced condition" isn't showing up logs.
My initial assumption is that perhaps this notification is being run before the substatus is even updated/commited and hence the Substatus CHANGESTO condition is failing.
Interestingly, if I remove the CHANGESTO condition and keep only Case Type = Fault condition and then run the background script, the email is being triggered.
EDIT: NEW FINDINGS
It appears that the "When to run" condition isn't being honoured for "Updated" checkbox in some cases. Here's what I tried:
(a) Used only "Case Type = Fault" under conditions
(b) Kept the gs.info statement inside "Advanced condition"
(c) Ran the background script and put the substatus to empty
(d) Boom! The log statement was visible and the email was sent out
(e) Then I ran the background script and put the substatus to SIIAM interface failure
(f) No log statement got printed indicating that some condition failed
(g) Then I ran the background script and put the substatus to empty
(h) Boom! The log statement was visible again and the email was sent out
(i) Ran the background script and put the substatus to Processing (which is valid value)
(j) No log statement got printed indicating that some condition failed
(k) Ran the background script but did nothing on the substatus value and put a work note
(l) Boom! The log statement was visible and the email was sent out
So for some reason it seems the "when record gets updated" condition isn't working whenever I try to put the substatus to any other value except empty. Any thoughts as to why this might be happening?
Solved! Go to Solution.
- Labels:
-
Scripting and Coding
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2022 10:47 PM
Caught the culprit. It was an "after" Business Rule that ran whenever substatus changes. In the script part, there was a setWorkflow(false) statement which was disabling the Notification engine.
To resolve it, I changed the order of the BR to 1001 as per https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0858407 and it started working now.
Thank you everyone for your suggestions. Turns out it was the dreaded setWorkflow statement that causing the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2022 12:15 AM
Oh yes, that is what I ensured before running the background script. The substatus value was "Processing", then I ran the background script which changed the substatus to "SIIAM interface failure". So it did change but notification did not fire.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2022 12:09 AM
Hi Nisar,
Sometimes changes to behaves weirdly. I have faced similar problem in past.
Please try below condition,
Case Type is Fault
AND
Sub Status is SIIAM Interface Failure
AND
Sub Status changes
This is equivalent to your required condition but with different way. Give a try, it should work.
Make sure that record has some other sub status than 'SIIAM Interface Failure' before executing script.
Let me know if you have any further queries.
Please mark this as Correct or Helpful if it helps.
Thanks and Regards,
Abhijit
Regards,
Abhijit
ServiceNow MVP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2022 12:16 AM
Tried it, no luck.
There seems to be some problem with the u_substatus field. I'll update my findings in the original post shortly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2022 02:44 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-17-2022 03:39 AM
I tried it and didn't work. I think the problem is that for some reason when I'm updating the substatus, the whole record is not being considered as updated therein failing at the very beginning phase of "When to run"