Status Life Cycle Execution

The elements in a status life cycle are executed in a specific order. For example, a life cycle might define the following:

  1. A subscription is currently in status Pre-Active. This status has a transition to status Active with the following configured:
    • MtxStatusConditionFirstActivity condition
    • MtxStatusActionActivateAllOffer action
  2. When a first activity occurs, the system checks to see if any transition in the current status has a MtxStatusConditionFirstActivity condition configured. Once the system determines that the condition exists and has been met and all filters have passed, the status object transitions to status Active. The condition and its filters are evaluated using the current status before the transition.
    Note: Pricing sees post-transition values. If a subscription transitions from Pre-Active to Active on an offer purchase, then, if offer purchase pricing looks at the subscription state, it sees Active.
  3. Once the transition has occurred, the system checks if any actions can be executed and if the execution is allowed. Actions are executed when all filters pass and the new status allows that action. (For example, you cannot cancel an offer if the new status does not allow that action.) The action and its filters are evaluated after the transition using the new status.
    The system finds that the MtxStatusActionActivateAllOffer action can be executed and all its relevant filters have passed. Therefore, all pre-active purchased items are activated.
    Note: The status transition remains regardless of whether the actions pass or fail (assuming they are allowed).
  4. If the executed action results in a new condition being met, that condition is processed separately.

At the end of the event that causes a life cycle change, life cycle logic is evaluated again and another transition may occur. For example:

  • Pre-Active to Active on an offer purchase.
  • Active to Suspended on a balance expiration.

If an offer purchase results in a balance expiration, then the engine transitions to Suspended before the event completes.

When a scheduled request to modify an object's status cannot be preformed successfully, the following notifications are generated:
  • MtxSubscriberStatusFailureNotification
  • MtxDeviceStatusFailureNotification
  • MtxGroupStatusFailureNotification
Note: Failure notifications are not sent if the modify request is triggered from a Subman API. Failure notifications are only sent if the modify request is triggered from a scheduled request.
For more information about status change failure notifications, see the discussion about status life cycle notifications in MATRIXX Subscriber Management API.
Status transitions due to MtxStatusConditionRecurringFailure and MtxStatusConditionRecurringSuccess are performed in the same transaction in which recurring processing occurs, and the object/offer status is updated instantaneously.
  • The PurchaseOffer, Recharge, Payment, and PaymentRefund APIs perform recurring processing and status transitions at the end of the operation.
    Note: The AdjustBalance API does not perform recurring processing as the AdjustBalance API is an administrative API to update balances.

    When a top-up offer is purchased or when making a recharge, payment, or payment refund request, recurring processing is triggered and offer and subscriber/group/device status transitions are performed based on the results of recurring processing.

  • At the beginning of processing a SubMan request, when retrieving the subscriber, group, or device object, recurring processing is performed first, followed by status transitions.

    When a SubMan request triggers recurring processing, offer and subscriber/group/device status transitions are performed based on the results of recurring processing.

For more information about the MtxStatusConditionRecurringFailure and MtxStatusConditionRecurringSuccess conditions, see the discussion about status life cycle conditions.