How can I stop one notification going by email to one particular person?

I was asked recently whether there was any way to stop one particular notification going to one particular user via email – the user wanted to receive all their other notifications via email, but not this one.

Since the user wanted to receive all their other notifications via email, it wasn’t a case of being able to change their notification preference, since that would stop all the others going out as well.  We could consider flicking the profile before sending the notification and then changing it back immediately afterwards, but I’m not convinced that this would work.  Also, it’s a pretty intrusive change to make to process, since you would need new logic before and after the notification activity.

So, there are two other ways that the client could do this.

Firstly, they could write a trigger on WF_NOTIFICATIONS which fires when a new notification is created.  The trigger would check whether the recipient is the user we are interested in and the notification type being created, and if so immediately set the MAIL_STATUS to SENT.  This would fool the mailer into believing that the notification had already been emailed, so would never go out via email.

The second approach would be to change the Workflow definition and include a post notification function for the one notification which performs the same logic – if the user is the one person who doesn’t want to receive the notification via email, then update the MAIL_STATUS to SENT again to stop the email being sent.

Both of these approaches have pros and cons.  Creating a trigger on the table may introduce a performance overhead – every notification which is created would need to be checked to determine whether to suppress the email being sent.  Creating a post-notification function means that changes need to be made to the Workflow definition, and the support guidelines would need to be checked before making changes to a seeded notification.  Also, if the notification already has a post notification function, then you would need to either change that PNF, or create a wrapper which calls the original PNF and then does the new logic.

There were three questions that I put to the client before recommending an approach to adopt:

  1. Is it possible / likely that more than one user will want this functionality?
  2. Is is possible / likely that the users might change their minds about whether they want this enabled or disabled?
  3. Is it possible / likely that the user(s) might want to include different notifications?

If the answer to the last question is “No”, then I would change the existing Workflow definition and include a post notification function.  If the answers to the other questions are “Yes”, but it still only applies to one notification, then I would still create a PNF to perform the logic, but build extra flexibility into the logic.  For example, I would also have a profile option set at the right level which indicates whether emails should be suppressed or not, which provides flexibility and ease of use to enable / disable the suppression of emails via the front-end screens rather than needing a coding change.

If, however, the answer to the last question is “Yes”, then I would define a trigger on the table which can then fire under multiple scenarios.  I would define a value set which dictates which notifications should be suppressed (either for a whole item type or on an individual notification basis), and have the trigger check the value set first to see whether this notification is one where email might not be needed.  If the notification is one which shouldn’t be emailed, then again I would have a profile option for the user / responsibility / org / site which determines whether this particular notification should not be emailed.  This may be more processor intensive than a quick and easy check of one thing, but it provides the most flexibility to the solution – no coding changes are required to add / remove notifications or people to the list, which means that changes can be implemented quickly and easily without the need for further testing to be performed.

In the end, the client adopted the post notification function approach and decided not to make it widely known that this was a possibility.  It may be that in future years, more notifications / users are required, at which point they should revisit the recommendations and switch to the trigger approach.  There is nothing wrong with the way they have gone – it meets their current requirements, but if those requirements change significantly in the future then a review will be required.

16 thoughts on “How can I stop one notification going by email to one particular person?

  1. Hello Maytt,

    Why do you want to go through the trouble of DB Triggers or Changing Workflow Modification. That’s laborious and not the proper way to do it.

    Just set the individual’s WF preference to other than (‘MAILHTML’ and likes) or just set to (receive to notification) that will not send email to that person.


  2. Hi Sunil,

    Changing the preference would stop all notifications to the user being received via email.

    In this case, the user should receive all notifications via email apart from one particular message. As I said in the second paragraph – “Since the user wanted to receive all their other notifications via email, it wasn’t a case of being able to change their notification preference, since that would stop all the others going out as well.”

    If the requirement was to stop one particular item type being emailed to all users, then the standard way to do this would be to define different mailers so that the message doesn’t get sent, but that would stop all users receiving the email.

    There is no standard way to stop one user (or a specific group of users) from receiving some (but not all) notifications via email.

    Hope that explains why you need to do it this way.


  3. Hi Matt,

    We have exact similar requirement. I tried by introducing a function after the notification was sent where-in I am updating the mail_status = ‘SENT’ for the notification. Still the email is being sent.

    Do I need to update any other columns or am I missing any thing? Please let me know.

    Appreciate your help.


  4. Hi Matt,

    Can you please provide a solution to the activity mentioned by Bharati as I have exactly same requirement and once the notification node is finished I guess the notification mailer automatically sends the electronic mail so the PNF would be called after the mail has been sent.

    Please reply asap.

  5. Hi Bharati,

    Are you including a separate activity after the notification, or is this a post notification function?

    If the mail status is set to SENT before the mailer processes the notification, then the email should not be sent. I don’t believe that you need to do anything extra.


  6. Can you please provide the pseudo code for writing a PNF also, please correct me if I am wrong.

    PNF is a pl/sql block which is called from the notification properties’ function name field. Am I right?

    If yes, then please check the link below and let me know how to get the activity ID. Sorry for bothering you so much, this is the first time I am developing a workflow.

    Thank you for your support.

  7. Hi,

    You don’t need to reference activity ID in a PNF – you would only need that to access any activity attributes, which don’t apply here.



  8. Hi Matt,

    Could you please let me know what you mean by notification type, are you reffereing to the columns message type or message name field in wf_notifications.


  9. Hi Charitha,

    Message name. The Message Type is the item type for the message – so if you want to stop everything for just that item type, then you can filter on that column.

    If you want to stop just one particular type of notification, then you need to look at the message name.


  10. Thank You for the response to my earlier post!
    What should I do to supress the notifications coming up in the worklist also?

  11. Hi,

    If you want to suppress the notifications coming up in the worklist, then you would have to automatically close them as soon as they are sent. Alternatively, you could modify the Workflow definition so that the notification is not sent at all in certain circumstances (or all circumstances if appropriate!).


  12. Did anyone get this to work? I also tried adding a PNF by putting in a custom package name/function in the Function Name section of the Timecard Approval Notification in OTL. Doesn’t seem that it was executed at all before of after the notification was sent.


  13. Matt,

    Great website/blog – thoroughly appreciated.

    We have a business requirement to suppress emails for certain notification types and would like to use the PNF route to achieve this.

    The notification is NOT an FYI notification.

    Can you confirm that the PNF gets called immediately after the notification activity has been processed? And if it does, then what is the funcmode that is passed to the PNF?

    My understanding was that the PNF is called when the notification state changes – not immediately after it has been created – but since you say you have this working at a client presumably I’m wrong 🙂


    – Matt Symes

Comments are closed.

By continuing to use the site, you agree to the use of cookies. more information

In common with almost all professionally run websites, this website logs the IP address of each visitor in order to keep it running reliably. This is also essential for protecting the website and its visitors from malicious attacks, including infection with malware.

This website provides information as a service to visitors such as yourself, and to do this reliably and efficiently, it sometimes places small amounts of information on your computer or device (e.g. mobile phone). This includes small files known as cookies. The cookies stored by this website cannot be used to identify you personally.

We use cookies to understand what pages and information visitors find useful, and to detect problems such as broken links, or pages which are taking a long time to load.

We sometimes use cookies to remember a choice you make on one page, when you have moved to another page if that information can be used to make the website work better. For example:
- avoiding the need to ask for the same information several times during a session (e.g. when filling in forms), or
- remembering that you have logged in, so that you don’t have to re-enter your username and password on every page.

You can prevent the setting of cookies by adjusting the settings on your browser (see your browser Help for how to do this). Be aware that disabling cookies will affect the functionality of this and many other websites that you visit.