Designing Notif. Download Types
You will need one notification download type for every type of notification your organization can send to service providers. To "design" your notification download types, list:
- Every outgoing notification that you documented under Designing Workflow Event Types.
- Every outgoing notification that you documented under Designing Workflow Processes To Support Outgoing Notifications.
- Every outgoing notification that may be triggered from within the system as described in System Conditions May Trigger Notification and Workflow. For each of these, consider creating a new value for the download type condition flag so that the download type is not hard-coded in the system process that creates the NDS.
We have populated the Notification Download Type column with a few classic examples:
|
Notification Download Type |
Download Type Condition Flag |
|
Inform all parties that customer is stopping service |
CUSTSTOP |
|
Inform all parties that meter has been changed |
METERCH |
|
Send consumption history |
|
|
Check if it's OK to switch customer from current supplier |
|
|
Reject request |
You should also consider the priority of each NDS type with respect to the other types.
Once you know the different types of download notifications, you have to determine the physical method used to route the notification to the third party. Refer to Designing Notification Download Profiles for how to do this.
If the outbound notification may be routed via XAI, you must define an XAI inbound service. This is used by the XAI MPL to retrieve information about the record related to the outbound message.
Refer to Configuring the System for XAI Messages for more information on designing your XAI outgoing messages.