I was asked recently whether there was any way that I could come up with where a user is presented with a warning message when they respond to a notification. The way that the client wanted the process to work was:
- When the user responds to the notification via the Worklist, then a warning message should appear.
- Once the system has displayed the warning message, the user should confirm their decision by responding again.
- If the response is not being provided via the Worklist, then no warning should be sent.
Workflow doesn’t offer this functionality as standard, so we need to develop something technical and custom to do this.
You could include a second “confirmation” notification in the process, so that this gets sent as a second notification as soon as the user responds, but that has two problems with it. Firstly, there is a disconnect between when the user responds to the notification and when the next notification appears. Secondly, you would need to include some extra logic which determines whether the first notification was responded to via the Worklist or not, and then conditionally branch to send the next notification or to bypass it. These two limitations mean that this really doesn’t work as a solution.
So, the way that we developed the solution was to include a custom post notification function for that notification, which handles the situation.
Firstly, the PNF checks whether the recipient is working via the Worklist or not. If the response is not via the Worklist, then the PNF ends indicating success.
We then added an extra attribute to the notification which indicates whether the warning message should be displayed or not. This uses the standard Yes/No Lookup Type, and defaults to “Y” indicating that the message should be displayed.
The PNF checks the value of this attribute for the notification – if it is “N” then there is nothing further to do, so ends indicating success. However, if the value is “Y” then we need to display the warning message to the user. The PNF sets the attribute to “N” so that when the user views the notification a second time, the warning message is no longer displayed. The code then retrieves the message to display from FND messages (we could hard code it in the PNF, but if the wording changes in the future, this would require a technical change, which I prefer to avoid if necessary), and sets it as an error message. The last thing that the PNF does is to return an error, which is then displayed to the user as the warning message.
There are two downsides to this approach, however. Firstly, the warning message will always be prefixed with an “Error” since that is what the code has actually returned. There is no way that you can code round this, however. Secondly, there is always a chance that the user will work in the following way
- Respond to the notification
- PNF displays a warning message to the user
- User does not immediately respond
- At a later point, the user responds again
- Since the warning message has already been displayed, it does not get displayed again
We could code round this issue by setting the attribute to a date including the time when the PNF fires the first time. When the PNF fires again, a check could be made against the current date and time versus the value in the attribute – if the second action is reasonably close to the first, then don’t display the warning, otherwise repeat the warning message.
The only reason we didn’t adopt this approach was that the business logic was quite clear that as long as the warning message was displayed once, that was sufficient from an audit perspective. Personally, I would have preferred to store a date value, as that also provides extra auditing, as the notification attribute will also include the date and time that the warning message was displayed. However, the client didn’t want to adopt this approach, and since it was their development team building the code, they wanted the simplest solution possible.
If anyone can think of an alternative approach to displaying a warning message, please let me know 🙂