I recently had an email asking for help with trying to work out why a notification wasn’t showing the approval history:
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.