Status Life Cycle Notifications

Status changes in an object status life cycle trigger notifications for the status change, and can also cause notifications to be generated for balance, product offer, and bundle expirations, and product offer purchases, cancelations, suspensions, and resumptions.

Note: Users assigned one of the predefined roles (owner, admin, or observer) have notification permission and can receive notifications for any of the enabled notification types. For more information about roles, notification types, and enabling product offer/bundle, balance/meter, and threshold notifications, see My MATRIXX Help.

Status Change Notifications

Notifications are 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. For example, to send a notification when the status changes from a current state of Active to the next state of Inactive, you define the notification on the Active status. "After" notifications in notification profiles assigned to status life cycles are not sent. If a SubMan API triggers a failure in the status change, an error is returned in the API response. If the system triggers a failure in the status change, for example, processing a scheduled request for a status change, a failure notification is generated.

For a description of each status notification MDC, see the discussion about status notification fields. For information about creating notification profiles, see My MATRIXX Help. For more information about object status notification fields, see the discussion about status notification fields. For more information about status change failure notifications, see the discussions about MtxDeviceStatusFailureNotification, MtxGroupStatusFailureNotification, and MtxSubscriberStatusFailureNotification in MATRIXX Integration.
Note: If a status transition is a result of an operation (for example, a purchase), then a single notification covers both the operation and the transition.

Balance Notifications

Balances and meters can be configured to send notifications when a balance is created and when a balance amount increases above a threshold or decreases below it. A subtraction from the available balance amount causes a decrease. An addition to the available balance amount causes an increase. It does not matter if the balance is prepaid or postpaid. The behavior is the same for both balance types. Pricing administrators set up balance notifications when configuring a balance definition. For information about how to configure a balance, see My MATRIXX Help.

Expiration Notifications

Expiration notifications can be generated for balance, product offer, and bundle expirations. Expiration notifications are defined in notification profiles which determine when expiration notifications are sent and the frequency with which those notifications are sent. For information about creating notification profiles, see My MATRIXX Help.

Product Offer Notifications

In addition to expiration notifications, you can configure product offers to trigger notifications when they are purchased or canceled. You can also configure group notifications to be sent to group members rather than group administrators. Pricing administrators set up product offer notifications when creating a product offer. For information about how to create a product offer, see My MATRIXX Help.
Note: Notifications can be suppressed by setting the Send Notification option of the MtxStatusActionCancelAllOffer status life cycle action to false.

Recurring Processing Failure Notifications

Configure balance templates, billing profile templates, and product offer cycle data in My MATRIXX to reference a notification profile that defines when notifications are sent after recurring processing fails (the failure to apply recurring charges). Notifications include the following information:
  • If the failure was for a balance cycle, billing cycle, or purchased item cycle.
  • If the failure was for a balance cycle, the balance template ID, and the balance resource ID.
  • The OID and external ID of the purchased item owner.
  • If the failure was for a purchased item cycle, the resource ID of the purchased item, the catalog item ID of the purchased item, and the external ID of the catalog item.
  • The start time and end time of the cycle period for which recurring processing failed.
  • An estimate of recurring charges and grants (advice of charge) for the cycle.
    Note: This information can be used to determine the amount of a balance recharge or payment. Credit limits of currency balances are ignored, and balances are not updated in the database. If recurring processing fails due to insufficient funds in a pseudo-currency balance or an asset balance, no estimate is provided. The advice of charge information is included in the MtxNotification balance impact fields.
Note: If a purchased item is in a recoverable state when recurring processing fails, a recurring failure notification and event are not generated.

Each recurring processing failure notification profile can be configured to send a notification upon a 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 occurs. If the balance instance is periodic, a balance expiration notification is triggered when the instance expires and when each individual entry in the instance expires.

If a recurring failure notification profile is defined on an event and the offer fails, a recurring failure notification is sent for the initial recurring failure. If you do not define the profile to send multiple notifications, later recurring failures within the same cycle do not generate a notification.
Note: Recurring processing failure notifications stop when recurring processing is successful. If recurring processing succeeds (for example, due to a product offer purchase) after a failure and before the time to generate the notification, the notification is not generated. For example, if the recurring failure event is set to be five minutes after the event, and recurring processing succeeds before the notification is scheduled to be sent, no failure notification is sent.

For more information about configuring balance templates, billing profile templates, and notification profiles, see My MATRIXX Help.

Suspend/Resume Failure Notifications

When a product offer is successfully suspended, an MtxOfferSuspendNotification is generated. If the scheduled product offer suspension request fails, an MtxOfferSuspendFailureNotification is generated. When a bundle is successfully suspended, an MtxBundleSuspendNotification is generated. If the scheduled bundle suspension request fails, an MtxBundleSuspendFailureNotification is generated.

When a product offer is successfully resumed, an MtxOfferResumeNotification is generated. If the scheduled product offer resume request fails, an MtxOfferResumeFailureNotification is generated. When a bundle is successfully resumed, an MtxBundleResumeNotification is generated. If the scheduled bundle resume request fails, an MtxOfferBundleFailureNotification is generated.

If the suspend or resume failure is triggered by a Modify Status SubMan API, errors are returned in the API response and no failure notification is generated. If the operation is triggered by the system, for example, processing a scheduled request, a failure notification is generated. For more information about using SubMan APIs to modify status values of subscriptions, groups, or devices, see the discussion about MtxRequestDeviceModifyStatus, MtxRequestGroupModifyStatus, and MtxRequestSubscriberModifyStatus in MATRIXX Subscriber Management API.

For more information about notifications, including object status notifications, see MATRIXX Integration.