Can I use a profile to conditionally send a notification via email?

Another one from the inbox – is it possible to send a notification via email based on a profile option (or some other condition)?  The requirement is that notifications should always appear in the Workflow work list, but for some notifications, there should be an additional copy sent via email.  If the condition is not met, then the notification should only appear in the work list.

Firstly, let’s look at how notifications are displayed.  Every notification is automatically available in a Workflow worklist – there is no way to stop that happening.  Additionally, as an “optional extra”, you can send the same notification via email, based on the following conditions:

  • The Workflow Mailer must be running
  • The Workflow Mailer must be configured correctly
  • The recipient role has an email address configured for it OR (if sending to a role which has multiple users assigned) the individual recipients have an email address configured
  • Either the global preference is set to receive email (and there is no over-riding preference set by the user) OR the user preference has been set to receive email

If any of those are not happening in your system, then the notification isn’t going to be sent as an email, regardless of what you want to happen.

So, it looks as if the only thing you can do is to either enable or disable the sending of an email.  BUT, there is an alternative which doesn’t quite meet the requirements, but might do the trick – it depends on what the business requirements are about whether the notification should be emailed or not.

If the business are concerned about sensitive information being emailed out, then there is an attribute which can be used for the message called #WF_SECURITY_POLICY which determines whether the notification should be sent by email or not.  If this is set to NO_EMAIL then an email will be generated which tells the user that they need to log into the application to be able to read it.  If that is what the business really want, then this is the way forward – if not, then adding the attribute may make the situation worse rather than better.

Aborting Workflows – Adding A Date Restriction

Back in April, there was a post on OTN relating to whether you could specify the date when aborting a Workflow process using the standard WF_ENGINE.AbortProcess API. The reason seemed to be that the user only wanted to purge data according to a specific date (e.g. up to the end of 2010).

As I said in my response, it doesn’t make sense to try to convince the system that you did something on a different date. If you set it to BEGIN_DATE+10, what happens to the child activities which occurred on BEGIN_DATE + 11? You would have an end date that was before the begin date, which doesn’t do much for any auditing and reporting that you want to do.

If the requirement is actually to abort and purge processes which started before a certain date, then the code below should help:

  FOR i IN ( SELECT item_type
             ,      item_key
             FROM   wf_items
             WHERE  1 = 1 ) LOOP
    WF_ENGINE.AbortProcess ( i.item_type, i.item_key );
  FOR j IN ( SELECT item_type
             ,      item_key
             FROM   wf_items
             WHERE  TRUNC(begin_date) <= TRUNC(TO_DATE('31-DEC-2010'
                                         ,'DD-MON-YYYY')) ) LOOP
    WF_PURGE.items ( j.item_type, j.item_key );

Modify the implicit cursor in the i loop to find the records that you want to abort, modify the cursor in j loop to include any other criteria.

The reason that you have to do them in loops is to ensure that the processes have all been aborted before trying to purge them - the process (and any child processes it spawns) must be complete before it can be purged. Likewise, when purging child flows, the parent must have completed before it can be purged (something I suggested as a feature many years back :))

How to populate the “From” field on a Workflow notification

Another quick one, but it pops up in fora and my email fairly regularly – when a notification is sent to a user / role, there is nothing in the “From” field to indicate who it actually came from. Sometimes, it’s there (in a seeded notification) and sometimes it’s missing, so how do we put something in there?

Firstly, the “from” needs to be defined in the Workflow Directory Service as a role – if you just want to put in “Bob Smith” for example, then you need to make sure that Bob exists in the directory. If not, then you need to create an ad-hoc role to use instead.

Once you have identified the role (and it may already be in your process) then you really should store that in an item attribute. Then you need to define an attribute on your message called #FROM_ROLE. You can set this to a constant, but I would recommend setting it to synchronize with an item attribute so you can easily change it later if necessary. Set the value of the attribute to the role that you want as the from, and save it.

Now, when the notification is sent out, the value will display the display name for the role. As a warning, though – messages aren’t versioned in the database, so you need to ensure that your changes (if you are using a new item attribute to synchronize with, for example) remain valid for any processes which are already running.

Icons missing in Workflow Builder

I recently had an email asking me what was wrong with their Workflow Builder installation – whatever they did no icons were appearing in the Builder.

Also, there was no Standard item type being opened – when the user tried to create a new Item Type using the quickstart wizard, they got an error message – and it wasn’t even a nice one, as it looked like the messages file hadn’t been installed correctly and all they got was an error name and code.

Some years back, I had exactly the same problem when I had installed Builder on a machine on client site. The installation process had “worked” correctly (i.e. Oracle hadn’t reported any errors), but obviously there was something wrong.

The problem was that the user I was logged in as did not have FULL admin rights on the machine – it had enough to make most of the install work and write some information into the Windows registry, but not enough to actually install EVERYTHING required.

So, the quick fix is to make sure that you are logging into the machine as someone with full rights (typically log into the machine itself rather than onto a network) and then do the install.

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.