Delegating or Transferring Notifications
When a user receives a notification which requires a response, they have a choice in how they can respond to it. They can respond, transfer, delegate, or ignore the notification – so what does each mean?
Respond
This would be the “normal” expected behaviour of a user (if that’s possible to pre-empt as a developer!). They receive a notification which asks them to do something, and they respond to it. In this case, the Workflow engine will check whether there is a Post Notification Function (PNF) tied to the notification. If there is, then the PNF runs in RESPOND mode, which is the usual mode to run. Once the PNF completes (unless it returns a status of ERROR), the Engine will then transition down the path from the notification and continue processing. If the flow doesn’t contain a transition that it can use (or a default transition), then the process will have the status set to #STUCK as it can’t go anywhere from the notification.
Transfer
Transferring ownership of the notification means that the person who is designated as the assignee becomes the owner of the notification. This allows users to completely handover any responsibility for the notification to another person – they will be shown as the new owner. When the notification is transferred to another user, the Workflow engine again checks for a PNF, and runs the code in TRANSFER mode. If the user transferring the notification included a comment, it is at this stage that it is written to the notifications table. The new owner of the notification will now see the notification in their worklist, and it is their responsibility to respond, transfer, delegate or ignore the notification.
Delegate
Delegating the notification of the notification to another user means that the new user is responsible for handling it, but the notification still remains owned by the original recipient. When a user delegates the notification to another user, the system will update the notification with any comment provided by the original owner, checks for a PNF and runs it in FORWARD mode (note the internal name actually makes more sense than the display name!). The new recipient will see the notification in their worklist, but when they respond to it, the original owner remains constant.
Ignore
If the user doesn’t respond to the notification, if the flow has been built to include a timeout transition, then the Workflow background engine will take that transition once it has timed-out. If the process does not have a timeout, and the user chooses t ignore the notification, then the process will just sit, waiting, until someone tells it to continue…
Transfer or Delegate?
So does the method of reassigning a notification really make a difference – after all they appear (superficially at least) to perform the same functionality, in that a new person is now responsible for doing something with the notification.
The best way to consider this is to look at delegating or transferring notifications in some real-world examples. Firstly, consider an expenses processing system (this could be bespoke, Oracle Internet Expenses, or some other expense processing system). A report is sent to a user, asking them to approve or reject an expense claim before it can be processed further. Once the notification has been approved, the system verifies that the person responding to the notification has the appropriate authority to approve the expense report.
If the notification has been delegated, then the owner of the notification will still be registered as the owner of the notification. When the process verifies that the approver has the appropriate authority to approve the report, it is this user who is checked. If the notification has been transferred, then the owner of the notification changes to the new user. In this case, when the process validates that the responder has the appropriate authority, the new owner will be checked. Assuming that the original recipient has an approval limit of £500, here’s how the Workflow engine interprets the approval limit for delegating or transferring the notification:
| Action | Recipient Limit | Approval Range |
| Delegate | £0 | Up to £500 |
| Delegate | £100 | Up to £500 |
| Delegate | £1000 | Up to £500 |
| Transfer | £0 | £0 |
| Transfer | £100 | Up to £100 |
| Transfer | £1000 | Up to £1000 |
The second example to consider is Oracle Purchasing. Within Purchasing, the workflow generates a notification and a document that is associated with the notification, which requires approval. If the notification is transferred, then the document is not transferred to the new user, and so an auditing capability is lost. Within Purchasing, notifications should never be transferred, only delegated. Indeed, the system now does not let you transfer notifications which require approval (see the Oracle Purchasing User Guide for more information).
Which leads nicely onto the final point that I want to make here:
Can I control whether users Transfer or Delegate notifications?
Within eBusiness Suite, you can. In standalone Workflow, you can’t as standard. If you need to manually include this functionality, then you should write a PNF which checks the mode – if the notification is being transferred instead of delegated (or vice versa), then you can error the PNF and get the user to change their reassignment method.
Within eBS, there is a profile which can be set called “WF: Notification Reassign Mode”. In some versions of the documentation, this is referred to as an “FND:” profile, but the name now starts “WF:” instead. The profile determines whether users are forced to use one reassignment mode or the other, or whether they should be given the option to determine which method to use.
The profile can be set at different levels, so you can enforce the Purchasing responsibilities to only allow Delegate, while Internet Expenses (for example) might only be allowed to Transfer notifications. You should set the profile to “Reassign” at Site level, which provides users with the choice, and then lock the reassignment rules down for each responsibility as required.
Finally, if you have used the “Grant Worklist Access” function within eBS, then the profile option is ignored, since this delegates the entire worklist to another user.
Leave a Reply