Status Notification Profiles
Notification profiles are reusable pricing components that define when expiration and recurring processing failure notifications are sent and the frequency with which those notifications are sent. Notification profiles can be assigned to each status in status life cycles. For a complete list of possible notifications, see the discussion about notifications in MATRIXX Integration.
- Expiration Notification Profiles — In My MATRIXX, expiration notification profiles can be assigned to balance, product offer, and bundle definitions
for expiration notifications.
Each expiration notification profile can be configured to send a notification on expiration and multiple notifications (minutes, hours, days, weeks, months, or years) before and after expiration. If the balance instance is periodic, a notification is triggered when the instance expires and when each period in the instance expires.
- Recurring Processing Notification Profiles — Specifies how long before recurring processing a notification should be delivered. The notification is only delivered before recurring process is executed. Each recurring processing notification profile can be configured to multiple notifications (minutes, hours, days, weeks, months, or years) relative to the time that recurring processing begins.
- Recurring Processing Failure Notification Profiles — In My MATRIXX, recurring processing failure notification profiles can be assigned to
balance cycle templates and billing cycle templates. Each recurring processing failure notification profile can be configured to send a notification on failure and multiple notifications (minutes, hours, days, weeks, months, or years) relative to the time of the initial recurring failure for the period in which the failure occurred.Note: If recurring processing succeeds (for example, due to a product offer purchase) after a failure and before the time to generate the notification, then the notification is not generated.
- Offer and Status Life Cycle State Change Notification Profiles — Status changes that occur in an offer or bundle can trigger status change notifications. Notifications can be generated for object status changes for devices, users, subscriptions, and groups on or before a status change as defined in the notification profile for the status life cycle. Notification profiles can be assigned to each status in status life cycles.
- Offer Expiration (Multiple Prior)
- Prior to Event 1 Month
- Prior to Event 1 Week
- Prior to Event 1 Day
- On Event.
This notification profile generates four notifications (three before expiration and one on expiration).
- Balance Expiration (Multiple All)
- Prior to Event 1 Week
- Prior to Event 1 Day
- Prior to Event 30 Minutes
- On Event
- After Event 1 Day
This notification profile generates five notifications (three before expiration, one on expiration, and one after expiration).
For any operation that could generate a notification (such as a balance expiration, status change, recurring failure, and so forth), only one notification is generated at a specific time. In addition, any change to an object state (balance, subscriber, offer, and so forth) causes the notification generation schedule to be re-evaluated. All notification generation times are relative to the calculated transition time. If status conditions change, any outstanding notifications are adjusted also.
Balance Auto-expiration
Assume a notification profile is configured to generate a notification one hour before a balance expires and at the time the balance expires (at two different points in time). If a status change causes a balance to auto-expire because the balance was fully consumed, only one notification is generated, even though the notification profile was configured to generate a notification an hour before expiration.
Transition Time Reset
Assume a notification profile is configured to generate a notification one week, three days, and one day prior to an auto-transition that causes a balance to expire. One week before the state transition, a notification is generated. A customer then performs a recharge on the balance that resets the auto-transition to two weeks. Again, one week prior to the auto-transition, a notification is generated.
Notification Relevance
You can configure the amount of time in which to send missed notifications during system configuration. This is the amount of time for which a notification is still relevant. The default is 14400 minutes (10 days). The example below uses a time of 720 minutes (12 hours), which in most cases allows relevant notifications to be sent. Configure the notification relevance by answering the following create_config.info question: Global:What is the maximum time in minutes do you want to allow to send missed notifications?
After making this change to the
create_config.info question, apply the configuration change.
For more information, see the discussion about applying MATRIXX Engine configuration changes in MATRIXX Installation and Upgrade.
Assume a notification profile is configured to generate a notification one week, three days, and one day before an auto-transition that causes a balance to expire. The notification relevance is configured to be 12 hours. Two weeks before the auto-transition, no notifications have been generated. A customer uses all data that causes a balance to expire and the new auto-transition is set to occur in two days. All outstanding notifications are re-evaluated to decide if they should be sent or whether they are too late to be relevant. In this situation, the one week and three days notifications are irrelevant. Only the one day prior notification is generated.
To send different notifications depending on tenant, use a notification profile selector, which selects the appropriate notification profile using a decision table. For example, a notification profile selector has two notification profiles (NP1 and NP2). Tenant X uses NP1 to send status change notifications three days before the transition while Tenant Y uses NP2 to send status change notifications one day before transition.