Yes I was just looking for the filter names.
I agree with you not having to modify if you do not need to and attempting to set the message tag to null before the execution of this filter. At this point I do not know how many use cases I might have either - on the face of it, it looks like just 2, but will need to think it over. Either which way - either setting that tag to null or overlaying the filter and adding conditions to it seem like the way to get there. I think I will lean more on setting the tag to null if it is easy to determine the execution order for that is - since both these filters for IM and CM are part of a guide, will need to check what order that guide is called from. Thanks for the answers. This helps. Joe _____ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of JD Hood Sent: Friday, August 21, 2015 10:28 AM To: [email protected] Subject: Re: Turning off general ticket notifications from ITSM modules during a transaction.. ** Hi Joe, I have not tried this, but the Run-If on HPD:INC:NotificationGenerator_899_PNPC`! is simply: 'z1D Notification Message Tag' != $NULL$ So the first thing I would try is building the workflow to monitor for your conditions where a notification should *not* fire (on submit, modify, whatever) and then make sure you $NULL$ 'z1D Notification Message Tag' before execution order 899. The first evaluation in your Run-If(s) should be 'z1D Notification Message Tag' != $NULL$, which means a notification is about to fire. So your Run-If(s) should be something along the lines of: 'z1D Notification Message Tag' != $NULL$ AND (any other field conditions where you do *not* want notifications to fire). Your one action would be a set fields mapping of: 'z1D Notification Message Tag' value of $NULL$ This is the first thing that comes to mind if I needed to do this with custom filters and avoid having to overlay & modify OOB filters. Not sure how many conditions and use-cases you need to monitor for, but I would try to have them all fire as close to execution order 899 as I could, just to be sure. Best of luck with it! -JDHood On Fri, Aug 21, 2015 at 9:51 AM, Joe D'Souza <[email protected]> wrote: ** Is that the only filter that controls ALL (customer, support, etc.) notifications? Joe _____ From: Mohammad Rehman [mailto:[email protected]] Sent: Thursday, August 20, 2015 5:27 PM To: Remedy ARS Cc: [email protected]; [email protected] Subject: Re: Turning off general ticket notifications from ITSM modules during a transaction.. Joe, I have similar case customization on Incident notifications. With My requirements I had to create overlay on notification filters to add the value. But If you simply want to send notification yes / no then you will have to modify one filter to set the qualification your new notification field value. Here is what i have done. custom field notification along with selection values. Filter to add your notification field in qualifications HPD:INC:NotificationGenerator_899_PNPC`! -Mohammad On Thursday, August 20, 2015 at 12:41:18 PM UTC-7, Joe D'Souza wrote: ** Is there a flag somewhere on the IM, CM, etc. modules that can be set during the transaction to not send out a notification, overriding the settings for notifications for that ticket? Due to the nature of one of my requirement, I would know if a notification must be or shouldn't be sent only during update. The problem is I do want the OTB notifications to happen as they should, but I need the ability to programmatically turn it off for a certain transaction if it meets a particular criteria - a criteria that that mostly depends on custom fields that will be created. I would prefer not to touch the OTB filters / workflow that sends those notifications but rather override what is set by that workflow by setting a value into a OTB field that signals no notifications action for that particular transaction. Is there an OTB field that might be able to control that? Joe _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
