Hello

I have a requirement to send a notification with attachment but attachment name should be attachment name. Is there any way to change the display name of the Attachment?

This is something that was also asked in the forum in June last year – where there are multiple attachments (or even if there is a single attachment), users like to see the details of the attachment rather than a generic “attached file” link, for example.

When the notification is built, any attached documents are included as attributes to the message.  The link to the attachment is created using the display name for the attribute in the text.  It is possible to modify the display name of an attribute programmatically (although this is NOT supported by Oracle since it would be a direct table update), BUT attributes aren’t versioned.  There is only one definition of an attribute within the process definition, so if we changed the display name, this would impact EVERY notification that uses the same message.

So, the quick and simple answer is “No”, and hopefully this quick post explains why you can’t.

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.

When I try to save the workflow, I am getting the error below:
WFPACTV_FAIL OPERATION=SAVE NAME=XXOM_P_VLVS_LN_FLW_GEN_SCH_DEF TYPE=OEOL
WFPACRV_REUSE_PROCESS NAME=XXOM_P_ASSIGN_VS_SO_LINE

What’s the problem?

The error is caused because Workflow will not allow the developer to re-use a sub-process within the same hierarchy, i.e. Start -> SUB1 -> SUB2 -> SUB1 -> End.  When I did my first Workflow project, we had a very complex process flow which managed sending messages via AQ from one system to a transformation hub, which then passed them onto a back-office system.  What was a simple message from the front-end became a series of simple messages in the back-end, and Workflow was used to manage the co-ordination between the systems.

What we found, however, was that in the front-end, we could build a message which allowed the user to enter a mailing address for the customer, for the product that the customer was buying (so different products could be posted to different addresses), for a proxy for a product and so forth – essentially we had four or five different levels where we wanted to do the same thing.  Unfortunately, because the “create an address” process could be called a number of times within the same hierarchy, we hit the limitation in Workflow that you cannot reuse the process.  As a workaround, we ended up creating copies of the sub-process and naming them differently (we added a different letter to the name), which became pretty annoying when it came to maintenance later on – if we had to make a change to one sub-process, we had to make sure that we were making the same change to each copy as well….

Why can’t you do it?

Here’s the background about WHY you can’t do it – feel free to skip ahead to my thoughts on bypassing the problem now.

Because of the way that the Workflow definition is stored in the database, if the same process is re-used, there is no way that the Workflow Engine can determine which time through the activities are being run.  For a single activity, when it is revisited, the previous visit is archived in the Workflow history tables.  For a series of activities (i.e. a sub-process), the same holds true when it is revisited – the whole process is recorded in the history tables.  However, there is a big difference between revisiting a process and reusing it.  If you are reusing the process, then there is nothing to archive – the previous use should remain in the current run.  When the activity then completes, the WF_ITEM_ACTIVITY_STATUSES table would have two records for the same activity – the first run and then the re-used process.  Sadly, the code which manages the update cannot take the two into account, so wouldn’t know which record to update.

If Workflow was being written today, then if the activity statuses used TIMESTAMP rather than a DATE to store the execution time (or even included a sequence number), then the Workflow Engine could more easily determine which record to update, to help bypass this limitation.  However, if you had a parallel branch, which routed to two identical re-used processes (I can’t see WHY you would do that, but it could be possible), then you hit the same limitation again – how do you identify within the Workflow tables which activity in the process is running???  Overall, it makes sense to include the limitation, IMO.

Ways Round The Problem

If there are only going to be a limited number of times that the process is going to be re-used, then I would be inclined to make a copy of the process and rename it slightly and use that.  That process is significantly easier if you know that the process is finalized, so that you won’t be needing to make the same change to multiple copies.  If you are going this route, then you need to ensure that the different process copies are sufficiently clearly labelled / documented / commented to allow you (or someone else) to maintain the definition going forwards.

If there are a large number of processes that need to be copied (I remember having copies A through to K of one sub-process!), then I would define the process as a separate, runnable process which is invoked as a child process with it’s own item type and item key.  There are no limitations on the number of times that the process can be re-used, and if the process is still in the same item type, then when it is created, the item attribute definitions will be the same – you just need to include something in your code which copies them from one instance to another.

One downside of implementing a parent-child relationship, however, is that when you look at the entire history of the process, it isn’t going to be all in one place – there will be some parts recorded in one process and others in other bits.  Also, I would be wary of using the standard WAITFORFLOW / CONTINUEFLOW activities to manage the flow, if there is a way that there could be more than one waiting process.  Instead, I would define some custom business events – have the main flow wait to receive the event, and the child flows raise the event.  This way, when you raise the event, you can pass attribute values easily back into the parent without having to directly call the WF_ENGINE APIs.

If I were building that first project from scratch, there are many things that I would change.  This would definitely be one of those.

I have a custom Workflow which has notification where in I am using Adhoc role to send notification to multiple users. The Expand roles checkbox is checked.
Now the issue is the Action History table which comes in the approval notifications does not appear in the notification sent to each user.  The history is visible to the user who was added first to the adhoc role (where the Notification Group ID = Notification ID), but for all the other users the history table itself is not shown in the notification.

I have tried using WF_NOTIFICATION(HISTORY) in the workflow message but this is unsuccessful.

This intrigued me for a while about why the history would appear for one user but not for any others, when the content should obviously be the same.  Then I considered the issue a bit more, and this turns out to be standard functionality.

Here’s a more detailed scenario.  A notification is sent to a role, which has four users assigned to the role.  The notification requires a response, and the “Expand Roles” checkbox is ticked so that each user receives their own copy of the notification.  The notification is accepted as approved when either 75% of the recipients have approved it or 50% have rejected it.  Within the notification, there is a history table.  Over the following few days, the following activities take place:

• Day 1 – Within five minutes of receiving the notification, the first approver responds with an approval.
• Day 1 – Within five minutes of receiving the notification, the fourth approver rejects the notification.
• Day 2 - The second approver asks for more information from the person who submitted the request.
• Day 2 – The third approver asks for more information from the first approver.
• Day 3 – The first approver answers the question from the third approver.
• Day 5 – The person who submitted the request responds to the question from the second approver.
• Day 5 – The second approver approves the request.
• Approval / rejection from the third approver is still outstanding.

At this stage, what should the approval history be showing?  As far as the Workflow process is concerned, the notification (although they all have different notification IDs) can only have one history.  So, what is the history?  Is the history of the notification which was sent to the first approver the same as that sent to the second?

At some stage, the Workflow product development team decided that it made sense that a notification could only have one history, therefore even when the role was expanded, only the first person in the role would have the history.  So, what was happening was expected functionality – only that one person will generate history in the notification.   (It turns out that there is a brief mention of this being standard functionality in Metalink note 431219.1)

So, what can be done about it?

There isn’t much that can really be done to circumvent the standard functionality.  I discussed the issue with another Certified Workflow Expert that I know and bounced a few ideas back and forth.

The first suggestion he made was to use the special attribute #RELATED_HISTORY on the notification, which allows you to include the history from one notification in another notification.  His thoughts were that if a post notification function were included, it might be possible to set the attribute on the second and third copies so that they include the history of the first approval notification.  However, when we looked at it a bit more, it became obvious that this idea won’t work.  The #RELATED_HISTORY attribute can only be used to associate different notifications together, since it needs to be set to the label for the notification to relate, and the attribute only works on an FYI notification.

The next suggestion was that a single notification could be sent (i.e. without expanding the roles) to an email distribution list.  This would allow the user to receive what appears to be their own copy of the notification and act on it, but means that there is no way that the voting requirements could be met, and would only allow a response via email if the flag was set to allow forwarded responses, since any response would come from a different email address to the one that was notified.  Depending on the exact business requirements, this may or may not meet the bill.

So, it comes to the final suggestion.  Rather than including the standard history within the notification, we could suppress it from the first notification and then replace it with a custom table.  Including an attribute as a PL/SQL document in the code to generate a table which provides the history of all the notifications would enable all copies of the notification to include an up-to-date history for all copies of the notification.  Setting the document ID to equal the notification ID would mean that you can programmatically determine the group ID for the notification and build a complete history of the process.

This turned out to be the solution that the client wanted, needed and implemented in the end, but for some clients it would be overkill.  I’ll ask for some screenshots to include, but am not hopeful given their penchant for security – failing that, I’ll try to come up with some examples of how we did it.

…Everything is working fine except the fact that when I go to the notifications Page from the WF Admin responsibility, I can only search for my own Workflows.  I can enter the Item Type and the internal name, but the field Workflow Owned By is not a LOV.  The field is appearing as a hard-coded value of my user name, so I cannot see any processes launched by anyone else.

The answer is that the ability to view processes which are owned by another user is restricted to either the user who has been set as the Workflow administrator, or if the administrator is set to a responsibility the user has been granted that responsibility.

In this case, the user was telling me that they had been granted the “WF Admin responsibility”, but that isn’t necessarily the same as being a Workflow administrator.  For example, the Workflow administrator might have been set to be an individual user (in standalone Workflow this was always set as SYSADMIN as standard).

If you have been granted the standard Workflow Administrator responsibility, you will be able to navigate the administration pages, although you won’t be able to modify any of those settings.  So, navigate to the Admin tab, which will show you who is the current administrator or which responsibility has been set:

In the above image, the user has used the Workflow Administrator responsibility to navigate to the administration tab, but cannot make any changes because they do not have the responsibility to perform any admin tasks.  If I grant the “Workflow Administrator Web (New)” responsibility to the user and refresh the page, I can now make changes because I now have the right access:

Once the user has been given the right responsibility, when they search for any Workflow processes, the previously hard-coded owner field is now an LOV.

I am wondering if it is possible to stop the workflow cancellation from being sent to a user when he workflow is cancelled. I realize there is a global profile setting but I can’t do it globally. It is a custom workflow that I am developing. I was looking into possibly using the #wfm_cancel template and hard code an email address into the peformer but that didn’t seem to work. Has anyone done this type of thing before or have thoughts on how this might be achieved.

Some years back, the global preference didn’t even exist – the cancellation message was always sent, much to the consternation of some of my clients.  The way that we dealt with the problem to suppress all the cancellation messages was to create a database trigger which fired when the record in WF_NOTIFICATIONS is updated.

When the global preference was introduced, this trigger became irrelevant and was disabled.  However, if there is a requirement to provide a conditional suppression of the cancellation message, the trigger can be extended to provide this functionality.

Firstly, to remove any need for hard-coding a list of messages which need to have the cancellation message suppressed, define a value set which will contain the notifications which we want to suppress cancellation messages.  The values in the value set can be either the item type internal name (if all the messages in the item type should not have cancellation messages) or the internal names of the item type and the message with a colon delimiter if a specific message should have the cancellation suppressed.

Once the values have been defined in the value set, then create a trigger on WF_NOTIFICATIONS to check whether the message is in the value set.  If it is in the value set, and a response is not required, and the notification is being cancelled, then update the record so that the notification appears to have been sent already by the notification mailer:

CREATE OR REPLACE TRIGGER XXX_STOP_CANCEL_MSG
BEFORE UPDATE ON WF_NOTIFICATIONS
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW

DECLARE

  dummy PLS_INTEGER;
  v_suppress_ntf          VARCHAR2(10);

  CURSOR c_check_value_set ( cp_vs_name   IN VARCHAR2
                           , cp_type_name IN VARCHAR2
                           , cp_msg_name  IN VARCHAR2 ) IS
    SELECT 'EXISTS'
    FROM   fnd_flex_values_vl       ffvv
    JOIN   fnd_flex_value_sets      ffvs
           ON ( ffvv.flex_value_set_id = ffvs.flex_value_set_id )
    WHERE  ffvs.flex_value_set_name = cp_vs_name
    AND    (    ffvv.flex_value = cp_type_name
            OR  ffvv.flex_value = cp_type_name||':'||cp_msg_name
           )
    AND    NVL(ffvv.enabled_flag,'N') = 'Y'
    AND    SYSDATE BETWEEN NVL(ffvv.start_date_active,SYSDATE - 1)
                       AND NVL(ffvv.end_date_active,SYSDATE + 1);

BEGIN

  IF     :new.status      = 'CANCELED'
     AND :old.status      = 'OPEN'
     AND :new.mail_status = 'MAIL'
     AND :old.mail_status = 'SENT' THEN

    BEGIN
      -- Check whether the notification type is in the Value Set
      OPEN  c_check_value_set ( cp_vs_name   => 'XXX_SUPPRESS_LIST_VS'
                              , cp_type_name => :new.message_type
                              , cp_msg_name  => :new.message_name );
      FETCH c_check_value_set INTO v_suppress_ntf;
      CLOSE c_check_value_set;

      IF v_suppress_ntf = 'EXISTS' THEN
        -- Record is included in the value set, so need to include it
        -- Check that the notification expects a response otherwise
        -- do not cancel it

        SELECT 1
        INTO   dummy
        FROM   DUAL
        WHERE  EXISTS ( SELECT NULL
                        FROM   wf_message_attributes wma
                        WHERE  wma.message_name = :new.message_name
                        AND    wma.message_type = :new.message_type
                        AND    wma.subtype = 'RESPOND' );

        :new.mail_status := 'SENT';
      END IF;

    EXCEPTION
      WHEN NO_DATA_FOUND THEN
        -- Not a response, so no need to cancel it
        NULL;
    END;
  END IF;

END;

As ever, if you are relying on the code sample here, it is provided without any warranty – test it fully before deploying to a production environment.

SQL script

The way that the standard Wait activity works (WF_STANDARD.wait) is that it firstly determines whether this is the first or second time that the activity has been visited.  If it’s the first time that the activity has been visited by the process, then the different activity attributes are checked and the “wake up” time is calculated (i.e. when should the process next do something).  Once the time has been calculated, the procedure sets the result to deferred until that time and ends.  If it’s the second time that the activity has been visited, then the process sets the result to complete and ends.

So, rather than a “Wait” activity, it is actually a “Defer Until” activity.  That may not sound like too much of a difference, but there is a fundamental one.  If I suggested that the process will “wait”, then the inference is that as soon as the process has waited for a given period of time, then it will continue – if I was telling a PL/SQL piece of code to wait for a minute then I would call DBMS_LOCK.sleep(60); and as soon as that minute was up, the process will automatically continue.

However, the standard Wait activity doesn’t actually wait and then continue, it defers processing and the Workflow Engine moves on and processes something else instead.  That’s because rather than waiting, the thread has been deferred until a certain point in time which corresponds to the wake up time.

Unfortunately, this means that you need to run something to process those deferred activities – the Background Engine (WF_ENGINE.Background).  One or more Background Engines will need to be scheduled to run at the right frequency to process your deferred activities – which is why sometimes you wait for the right period of time (your Workflow got to the Wait activity just before the Background Engine ran), a short amount of time (the process got there and waited a little while until the next scheduled run of the Background Engine started), or you had to wait a long time (the Background Engine isn’t scheduled at the right frequency to meet the process needs).

Determining the number of Background Engines required, and their frequency of scheduling, is a bit of a dark art – each enterprise will need to monitor that the Background Engines are run at a suitable period but one that isn’t going to thrash the database into submission.  If, for example, you need the process to wait for 10 seconds before continuing, then you need to schedule a background engine to run every 9 seconds or less, so that the wait cannot get to more than 10 seconds.

Having something wait for a short period of time sounds wonderful in theory (“Oh, we’ll just have the process pause for a few seconds while XYZ happens”) but can have a significant impact on the overall performance of the system.  As soon as I hear someone suggest such a thing (which is fairly often!) then the question I always ask is “Why?”  What is so important to the process that you need to wait for 10 seconds, but can’t wait for 5 minutes?  This is particularly appropriate if you are then sending notifications which require a response – you want to pause the process for a minute, to get all the data, so you can send it in an email??

If you really (and I do mean really) need a short wait, then you need to consider what the triggering mechanism is – exactly what are you waiting for?  If that’s something that can be determined by a change of state somewhere then you are better off including a pause in the process via a Business Event and then have your triggering condition raise the event to show that it has completed the work and the process can restart.  Some developers (more than I care to remember!) have a tendency to include a short wait, then a check to see whether the job has completed, and if not, then loop back and wait again.  If you change the development approach to an event-driven one, then this becomes redundant – and it means that if something happens to prevent the action taking place, your Workflow isn’t going to loop and loop and loop, which adds lots more audit and history to the process than you really want.

As a final thought – I have NEVER used a standard Wait activity, since I started with Workflow development.  There are better ways to do it, and always have been (even before Business Event System was invented).

—

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.

I was working recently with a client on an upgrade from 11.5.9 to Release 12, which also throws up an anomaly – there are some notes types defined in an AOL lookup where the application ID is set to CRM Foundation.  This means that the list of notes types available now includes some which you cannot query in any other form in the eBusiness Suite.

So, firstly, we need to make those obsolete, incorrect notes types visible to the lookup screen, so that at least we are aware that there are additional notes types that are in the system – if we can’t find them, we can’t exclude them!

The way that this needs to be done is documented in Metalink note 813677.1.  The note instructs you to delete the notes from the system, but I am always somewhat wary of doing this, in case at some stage they were available and have been used.  Before doing anything with the values, I would recommend that they are backed up into a custom table, just in case we need to revert them at any stage:

CREATE TABLE xx_obsolete_lookups_backup AS
  SELECT *
  FROM   FND_LOOKUP_VALUES
  WHERE  lookup_type = 'JTF_NOTE_TYPE'
  AND    view_application_id != 0
/

Instead of removing them completely, run the following SQL which makes them visible but are clearly obsolete:

UPDATE FND_LOOKUP_VALUES
SET    view_application_id = 0
,      meaning = 'OBSOLETE - '||meaning
WHERE  lookup_type = 'JTF_NOTE_TYPE'
AND    view_application_id != 0
/

Now, if you navigate to the AOL lookups for the JTF_NOTE_TYPE lookup, the list is now at least complete.  Ideally, you would then just be able to end-date or disable the lookups, but those fields are protected against update.  So, the next step is to create an exclusion list of notes types that we aren’t interested in.

Using the CRM Administrator responsibility, navigate to Task and Escalation Manager > Setup > Object Meta-data and create a new Object Type which will store the list of notes that we aren’t interested in.

For example, I use a name “Unwanted Notes Bin” and code “XX_UNWANTED_NOTES”.  Set the Application to “CRM Foundation” and (this is the important bit), on the Usages tab, ensure that there is a record for object user is “NOTES”, as per the following example:

At this point, depending on how many notes types you want / need to exclude, we hit the really dull part of the configuration – map the notes you want to exclude to the new object type.  Again using the CRM Administrator responsibility, navigate to Notes Setup > Source and Note Type Mapping.  Create new records for each note type you wish to exclude – the Source Object should be the name of the object type you have just created, and then include the note type you wish to exclude.  The screenshot below shows my example exclusion list:

If you are doing an upgrade and had to run the SQL at the start of this post, ensure that you add the notes which begin OBSOLETE to the list as well.

Once you have completed the list and saved it, when you next try to add a note to a service request from an email, the list of note types should be what you want to see.  The two screens below show how the list now changes from this:

to this:

The list of note types available is now governed in two ways.  Firstly, all note types which exist in the custom object type we created here are now excluded.  Secondly, all note types which have been mapped to the Service Request object type will be enabled.  If there are conflicts between the two of these, then the second takes priority over the first.

So, if you are working on a system where you need to grant access to HR information types to responsibilities which are not within the HR area (e.g. CRM-based responsibilities), then there is no obvious way to do it.  In this kind of situation, there may well tend to be over-use of responsibilities since an HR and CRM responsibility is now needed to provide the access.

The way to reduce this duplication is to add the seeded HR security menu to the seeded Service menu as follows.  Using the System Administrator responsibility, navigate to Application > Menu and query the menu CSX_CUSTOMER_SUPPORT.  Add a new entry for the submenu UK HRMS SECURITY:

Once you have saved the new menu, navigate to the Service responsibility and you will have access to the form to enable you to map access to the information types:

Now when you open the form, you can easily map the required access.  The screenshot below shows adding different information types to the seeded Service responsibility:

This little tip comes courtesy of Davyd Parry.