Different email notification when REQ is closed

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-02-2018 01:33 PM
Hello, currently I have a business rule to set the RITM Stage, and an event in a catalog item workflow to set the RITM stage and state as "Closed Incomplete", respectively, when the SCTASK is set to "Closed Incomplete".
When the RITM closes as a result, the REQ approval changes to "Rejected" and it is closed out.
Currently, there's an email notification set up on the sc_request table named: "Request Completed".
This notification is set to send when the REQ active flag changes to false:
and it sends the following:
I created a copy of this notification named "Request Closed Incomplete" and changed the subject to say: "Your request ${number} has been closed as incomplete", using the same condition as active flag changes to false, but adding another condition where the approval changes to rejected:
When a service request is closed as incomplete (Approval changes to rejected), it ignores my second notification condition and sends the "Request Completed" notification rather than the "Request Closed Incomplete" notification:
I need some help getting the conditions to actually take effect so it sends the correct notification. I checked and there's no Order field on the notifications so I can't prioritize one over the other.
Can anybody provide a solution?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-02-2018 05:26 PM
Your first email notification is still being sent out because the conditions of 'Active changesTo False' is still being met. In order for this to work, you'll need to make the conditions mutually exclusive so only one or the other gets sent out. Try these conditions instead.
Notification 1 - 'Active changes to False and Approval is not Rejected'
Notification 2 - 'Active changes to False and Approval is Rejected'

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-03-2018 06:12 AM
Mark, thanks for the reply -- I had already tried this approach and it doesn't appear to work:
And:
When I tested this, the resulting notification that sends out is still the Request Complete. The REQ is closed (active changes to false) and it sends the first of the two notifications:
It's almost like it ignores the second condition.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-03-2018 07:01 AM
Maybe, but maybe it's a timing thing with the approval field. Can you try with the request state field? Closed complete/Closed incomplete (or whatever the status is in your instance). You could also try adjusting the email weight so that the 'Rejected' one always gets hit first as explained here...
https://docs.servicenow.com/bundle/jakarta-servicenow-platform/page/administer/notification/task/t_CreateANotification.html
One other thing to check on email weight is if either of your notifications has a weight of '0' it will be sent all of the time...as long as the conditions are met.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-03-2018 08:08 AM
I set the weight of the OOB notification to 10 as an example, and the notification that I made to a 20 and it still always prioritizes the OOB notification. If I set the notification to inactive, it will use my notification. It's disappointing that the second conditional is not changing anything.
The doc that you linked shows that both notifications should appear in the outbox with one set as ignored, while the other sends. In my outbox, it only displays the OOB notification, completely ignoring the second.
Pic from the doc:
Pic from my instance:
As for REQ State, I cannot get the state to change via business rule depending on the RITM state being set as closed incomplete. The REQ state seems to be much more complicated, so I reverted to using the approval as the deciding factor.